FARMVerify a published post and avoid duplicate retries
Learn how to interpret PhoneFarm jobs and proof reports, distinguish published, pending and uncertain outcomes, and use a publication log before retrying.
Publication is confirmed by the resulting content on the intended account. A job status, a screenshot and a live profile each provide different information about that result. Read them together, especially when a phone disconnects or a task finishes without a clear confirmation.
This guide explains how to verify a post and decide whether another attempt is appropriate. It is useful for the first run, for daily operations, and for the frustrating case where the dashboard reports a problem even though a post may already exist.
Why a task can finish without a clear publication result
A publishing workflow crosses several boundaries: PhoneFarm saves a request, prepares the file, operates the phone, submits inside the app and checks the result. A failure after submission can leave the final outcome uncertain.
For example, TikTok might accept the upload just before the live connection drops. The dashboard can lose confirmation while the platform continues processing. Repeating the entire task immediately would risk submitting the same content twice.
The reverse can also occur: a task reaches the composer, takes a screenshot and stops before publication. A screenshot exists, but its contents show that the post was not completed. Evidence must be interpreted, not merely counted.
Use three sources of information
1. The Publish jobs row
In Videos → Publish jobs, identify the correct row using platform, video, caption and time. Read the current status and any error. If you are inspecting a different job from an earlier attempt, you may draw the wrong conclusion about the latest run.
A saved job is useful for tracing what was requested. It is not a substitute for finding the final content.
2. The Proof report
In Proof reports, match the phone, time and caption. Open Screenshot when available and read Next step. Determine what stage the image actually shows: source selection, composer, upload progress, account profile or a completed post.
Check that the screenshot corresponds to this attempt. A previous successful post on the same phone does not prove that the current asset published.
3. The account inside the app
Open live control for the selected phone and inspect the intended account's profile. Find the matching content and open it. Compare more than its thumbnail: similar videos can share a first frame while showing different products or captions.
Record the post URL when one is available. The combination of account handle, post link, asset version and observed time gives you a much stronger record than “green check in dashboard.”
Check the content, destination and visibility
Use the following inspection for a confirmed post:
| Question | What to inspect |
|---|---|
| Is it on the right account? | Exact handle, not only display name or avatar |
| Is it the right video? | Opening, recognizable middle section, ending and sound |
| Is the text correct? | Caption, product references and required disclosure |
| Is the result in the expected state? | Published content versus a draft, processing screen or restricted item |
| Does its visibility match the intended audience? | The app's current visibility setting and any platform notice |
| Can someone else identify it later? | Post URL or another specific reference plus the observation time |
You do not need to wait for high view counts to verify publication. A correctly published video can have low initial distribution. That is a performance question, not proof that the upload failed.
Classify the result before choosing an action
The following are operating categories for your log; they are not a promise that every label appears verbatim in PhoneFarm.
| Result | Meaning | Next action |
|---|---|---|
| Confirmed published | Matching content is visible on the intended account in the expected state | Record the link; do not retry |
| Confirmed stopped before submission | Evidence shows the workflow never submitted the post | Fix the failed prerequisite, then prepare a new attempt |
| Platform processing or review | The app indicates it is still handling the submitted content | Follow the platform state instead of starting a duplicate |
| Uncertain | Available evidence cannot establish whether submission completed | Inspect the account and task further; ask for help if ambiguity remains |
| Wrong result | Content appeared, but the account, asset, caption or visibility is wrong | Handle that specific published result deliberately; do not disguise it as a failed upload |
An empty profile check is useful evidence, but timing and processing matter. Combine it with the task stage and platform notices before deciding that a new submission is safe.
Use the publication log
The downloadable publication log is a CSV you can open in a spreadsheet. It includes one clearly marked fictional example. Remove or replace that row before using the file for your actual work.
Identify the attempt: attempt_id, task_reference and campaign_id connect the job to the work being done. Give a retry its own attempt ID and use retry_of to point back to the earlier attempt.
Identify the destination and asset: account_id, account_username, phone_reference and asset_version specify where the work ran and what it used. A generic title such as “new video” cannot distinguish two revisions.
Record timing: intended_at, timezone and observed_at distinguish the planned time from when someone checked the result. Include the timezone so an operator in another country can interpret the record correctly.
Record the outcome: outcome, post_url, evidence_reference, operator and next_action explain what was found and what remains. Keep evidence references descriptive and avoid putting passwords, verification codes or private account recovery information in the sheet.
Worked example: connection drops after upload
You start one approved product demonstration on phone Brand-US-01. The job later reports a connection problem. The proof image shows upload progress, so it does not tell you whether TikTok finished processing.
You mark the attempt uncertain, reconnect to the same phone and open the intended profile. If the matching video is present with the correct caption, update the record to confirmed published and save its link. No retry is necessary.
If the app shows an unfinished composer and the task details establish that submission did not complete, resolve the connection problem before trying again. If you cannot tell whether the old task is still active, check its current state or contact support rather than running a manual post and an automated retry simultaneously.
Make verification part of the normal workflow
For a small operation, inspect each result after the run. As volume grows, group results by phone and campaign while keeping exceptions visible. One unresolved attempt should not disappear into an aggregate success count.
Use the same definition of “published” across operators. This prevents one person counting saved jobs while another counts live posts. Your weekly report can then compare confirmed outputs, failed attempts and unresolved outcomes accurately.
For failure diagnosis, continue with publishing tasks that failed or stalled. For performance after publication, use the weekly measurement guide.