FARMTroubleshoot a PhoneFarm publishing job that failed or stalled
Diagnose jobs by their first failed stage: selection, readiness, queue, media preparation, app login, submission or final proof, and retry without duplicating posts.
A publishing task can stop before it reaches the phone, while preparing the video, inside the app, or after the platform has accepted the post. Those failures look similar if you only see a final status, but they need different fixes.
Start by preserving the job you already created. Identify its video, platform, phone and time. Then find the last stage known to have completed. This lets you repair the relevant dependency without creating unnecessary uploads, purchases or duplicate posts.
First: could the post already exist?
If the task reached upload or submission, open the intended account and inspect the profile before retrying. Match the actual video and caption, not only the thumbnail. Review Proof reports and any available screenshot.
If the post exists correctly, record it as published even if the task lost a later confirmation. If the result remains uncertain, keep it uncertain while you investigate. The publication verification guide explains the decision in detail.
If the failure clearly happened before an app action—such as a missing video selection or a stopped phone—move directly to that earlier stage.
Use this diagnostic map
| Last successful stage | Current symptom | First thing to investigate |
|---|---|---|
| Nothing selected | Run action disabled | Video, platform and phone selections |
| Selections prepared | No ready phone/platform pairs | Phone readiness matrix |
| Plan saved | Work remains queued | Displayed timing, earlier work and current task state |
| Library asset selected | Media cannot be prepared | Source preview, URL accessibility and phone connection |
| Phone opens app | Login or verification prompt | Correct account and recovery access |
| Composer reached | Task cannot finish | Visible app requirements, permissions or validation |
| Submission may have happened | Failure or missing proof | Actual profile and proof report before any retry |
| Confirmed post exists | Low views | Content/account performance, not publication recovery |
When Run now is disabled
The Videos action label tells you what is missing: Select videos to continue, Select platforms to continue, Select phones to continue, or No ready phone/platform pairs.
Resolve that specific selection. Selecting a phone alone does not choose an asset or platform. Selecting every platform does not install the apps on the phone. For a first diagnostic run, reduce the intended selection to one approved video, TikTok and the correct phone so the missing dependency is obvious.
Read the Phone readiness matrix. A stopped phone needs to be made usable. An app-missing result needs an installation. An unavailable account needs inspection inside the app. A session that will be checked before dispatch is not the same as a confirmed login failure; inspect the live profile to understand the current state.
When some selected combinations are skipped
The Videos interface can warn that certain phone/platform combinations will be skipped. Each platform requires its corresponding app and account readiness on the assigned phone.
The displayed plan keeps videos paired with their originally assigned phones. It does not automatically move a video to a different phone just because the first one cannot publish to a selected platform. Check the assignment summary and any message about more slots or posting times being needed.
This matters for account correctness: redistributing a video to an arbitrary available phone could send it to a different account. Resolve the missing prerequisite or revise the plan deliberately, then review it again.
When a saved task has not started yet
Run now uses the queue; it does not mean the app will submit immediately when you click. Read the timing explanation in the interface and inspect the saved job's schedule and status. A task that is not due yet should not be diagnosed as failed simply because no post exists.
Check for other work on the same phone and whether the task is still progressing. Refresh the task status through the available Refresh control when shown. Refreshing asks for current information; Retry creates another attempt and should be reserved for a resolved failure or a known safe repeat.
If the state remains unchanged beyond the expectation shown by the product, record the schedule, current time with timezone, phone reference and job reference. Support can investigate that particular queued task. Repeatedly creating new plans adds more work without revealing why the original has not advanced.
When media preparation fails
Play the exact asset in Videos. If it does not play there, resolve the source or upload problem first using media troubleshooting.
If the preview works, check whether the source is an external URL that expired or requires access. Then check the target phone's internet connection. A working browser preview on your computer does not prove the phone can retrieve the resource needed during publication.
If the asset reaches the app but will not import or play, inspect the app's message and the export format. A supported library container can still contain an encoding the destination app cannot use. Create a clearly versioned compatible export if needed, then explicitly select the corrected asset for the new attempt.
When the app opens but publication stops
Open the phone in live control and look at the exact screen. Common distinctions include a login page, security challenge, permission request, unsupported media message, incomplete composer or an account restriction notice.
For login or verification, use account troubleshooting. For general loading failure, test the phone connection. For a visible app requirement, understand what is missing before continuing the workflow.
Avoid taking over the phone while the original automation is still actively operating it. Manual taps can change the state underneath the task. Inspect the current task status and coordinate any cancellation or intervention using available controls before manually finishing the same post.
Read Publish jobs and Proof reports together
In Publish jobs, match the row by platform, video, time and caption. Read its error. In Proof reports, match the phone and time, inspect Screenshot, and read Next step.
A screenshot of a profile may help confirm a post, while a composer screenshot may explain why it needs attention. A blank proof field means you lack that evidence; it does not independently prove that no post exists.
If the report requests review, investigate the requested condition. Do not treat every report as a green light to retry the same content.
Retry only after answering three questions
- What failed? Name the stage and observed condition, such as missing TikTok installation or inaccessible source URL.
- What changed? Confirm the dependency has been corrected, rather than simply waiting and clicking the same button.
- Could the earlier attempt have published? Check the account and task state when submission was possible.
Use Retry where the relevant task exposes it, or create the appropriate new run after those checks. Keep the old attempt reference so you can understand the history. If the earlier result is still ambiguous, contact support before creating another potentially public post.
A useful escalation report
Include the job reference, phone reference, intended account handle, asset version, time and timezone, current status, visible error, last completed stage and whether a matching post exists. Add the proof screenshot if it explains the issue, with private information removed.
A report saying “library preview plays; phone opens TikTok on the correct profile; task stopped at the composer with this message; no matching post found at 10:12” is much more actionable than “automation broken.” Use the support template to send the relevant details.