FARMGet help from PhoneFarm support
Find the support route and send the right details for setup, live control, networking, uploads, publishing or billing, with copyable examples.
Use PhoneFarm support when a product workflow is blocked, a result is unclear, or a purchase or invoice needs investigation. The most useful report identifies one affected phone or task and the first step that failed.
The dashboard's Contact section currently lists support@phonebase.co. You can also open the PhoneFarm dashboard to use its current contact details. For a new managed-service or fleet-sizing conversation, use the booking section.
Choose the right route for the problem
PhoneFarm can help with dashboard access, phone setup, live control, configured connections, supported app workflows, media handling, task results and PhoneFarm billing. A social platform's password recovery, account ownership decision or appeal still belongs to that platform's official process.
If you do not know which layer is failing, describe what you see and the last successful step. You do not need to diagnose the root cause before asking for help.
| Problem | Most useful information to include |
|---|---|
| Purchase or setup has not completed | Purchase reference, selected country, current setup step and visible message |
| Phone is running but screen will not connect | Phone reference, live-control state, whether Play/Wake/Reconnect changed it |
| Phone or proxy has no internet | Phone reference, verification result, whether pages load inside the phone |
| Video upload fails | Filename or title, extension, size, error, whether source and library preview play |
| Publishing job fails | Task reference, phone, platform, asset version, last completed stage and whether a post exists |
| Billing discrepancy | Invoice/purchase reference, amount/date and the particular line item in question |
Describe the expected and actual result
Start with one sentence that tells support what you were trying to do. Then state what happened instead. Include the first observed failure time and timezone, plus the last time the same workflow worked if you know it.
For example:
I opened phone Brand-US-01 to publish an approved TikTok video. The dashboard shows Running, but live control stays on Connecting and no phone image appears. This started at 09:40 America/Los_Angeles. The same phone was usable yesterday afternoon.
This fictional example gives an identifiable action and symptom. “The farm is broken” does not tell support whether the problem is payment, setup, media, an account or the live screen.
Explain the scope
Say whether one phone, several phones or the whole account is affected. If several phones fail, mention anything they share that you already know, such as the same proxy supplier or the same app workflow.
Describe the practical impact: unable to complete first setup, unable to access an existing account, several approved posts waiting, or uncertainty about a submitted post. That helps separate an access issue from a question about how a feature works.
Do not guess that the same cause affects every device simply because one failed. Report observed facts and label anything you have not checked.
Include the minimum useful evidence
A screenshot of the visible error or state is often enough to begin. Include the phone name or reference and task/job reference where available. For video work, specify the asset version so support can distinguish similar exports.
For a publishing issue, explicitly say one of these:
- The matching post is visible on the intended account, with its link if available.
- No matching post was found in the views checked, at the stated time.
- The publication outcome is still unknown.
That distinction helps avoid a duplicate retry. A connection failure after submission is different from a task that never reached the app.
Remove secrets before sharing
Crop or redact account passwords, proxy usernames/passwords, verification codes, recovery keys, full payment-card details, tokens and private customer messages. Check browser address bars and surrounding panels as well as the main error message.
Keep the original privately if it contains context that may later be needed through an appropriate channel. Do not upload a large raw browser export containing unrelated sessions or credentials when a focused screenshot explains the issue.
For a private video, begin with its technical properties and the error. Ask how to share the actual file if support needs it for diagnosis.
Copy this report template
Subject: [Phone or task reference] — [specific failed action]
What I was trying to do:
What happened instead:
First observed time and timezone:
Last known successful time, if known:
Affected phone(s):
Task/job or purchase/invoice reference:
Platform and account handle, if relevant:
Asset title/version, if relevant:
Last successful step:
Exact visible message:
Actions already tried and the result of each:
Does a matching published post exist? Yes / not found / unknown
Attached evidence:
Current impact:
Do not fill every field if it is irrelevant. An invoice issue does not require a video asset, and a file-format rejection does not require a proxy password.
Example: a useful publishing report
The following is fictional and illustrates the level of detail:
Task PUB-EXAMPLE-01 on Brand-US-01 used lamp-demo-v03. The library preview plays correctly. TikTok opens on the intended brand profile. The task stopped after the upload screen at 10:12 UTC, and the proof report asks for review. I checked the profile at 10:16 UTC and could not confirm a matching post. I have not retried. The screenshot shows the current app state.
Support can now focus on the transition after upload. The report also makes it clear that a retry could create a duplicate if the original post is still processing.
Keep follow-up in the same conversation
Reply to the original support conversation with new observations and timestamps. If another operator takes over, share the existing reference so the team does not investigate the same incident independently.
Record any action you take while waiting: reconnecting, changing a proxy configuration, resetting a password, retrying a task or manually publishing. These changes can affect the diagnosis and the final outcome.
When support suggests a fix, repeat the specific check that originally failed. For live control, confirm the screen responds. For networking, test from inside the phone. For publishing, inspect the actual post. For billing, review the affected record and confirmation.
Useful checks you can make before contacting support
If they fit your symptom, the live-control, network, upload and publishing guides can identify the failed layer. You can stop and contact support as soon as the next step is unclear; there is no need to reset a device or repeat a payment to prove that you tried enough things.