Skip to main content
An account has stopped working and its antidetect browser shows an issue status. The status pill is the diagnosis, and each fault has exactly one fix.

​
Read the status first

Open Senders, click the account row, open the Browser tab of the drawer. The first four statuses below are exactly what the Browser issue filter chip on the list selects.
shared_out and subscription_required are HOLD states, not failures. The row action reads Parked, no browser action available, and a run call against either is refused with HTTP 409 and error.context.reason = "invalid_status_transition".

​
What the platform already did

start_issue, login_issue and restricted never recover on their own. A sync run that hits one of them re-defers every 30 minutes, indefinitely, with wait_reason = "browser:start_issue", browser:login_issue or browser:restricted, until a person or an API call intervenes. A browser that is merely waking re-checks every 60 seconds instead.

​
Ordered checks

Stop as soon as one of these explains what you see.
  1. Confirm it is a fault, not a hold. shared_out and subscription_required are parked on purpose, and no lifecycle action is available.
  2. If the pill is red, read which red it is. login_issue goes straight to re-login; restarting it will not help. restricted goes to LinkedIn first: a re-login cannot clear it.
  3. Read the reason. On the Browser tab, scroll to Browser event log. The newest error row names the cause in its event_type, code and message.
  4. Restart once. For start_issue or running_issue, use Restart now on the drawer banner, or Restart in the row action menu. Most clear on a fresh start, so give it one attempt and watch the status.
  5. Only then look at the proxy. If the restart lands back in running_issue, run the connectivity and location checks over the API (antidetect-browser-proxies/check-proxy-connectivity and check-proxy-location). See proxy troubleshooting.
  6. Escalate. client_error_investigation is the platform saying it has stopped guessing and the cause is on your side: fix what Last error names, then Restart. support_error_investigation means the cause is ours (or unclassified): our team is already paged, there is nothing to do on your side.

​
start_issue: nothing came up

Two physically different things produce it, and the event log says which: nothing ever launched, a host-side or network failure that killed the launch before a browser existed (usually a raw error string, for example a DNS failure), or the process came up and the handshake did not, where the post-start check that confirms the LinkedIn session never completed. Both leave the browser powered off, because the node tears down its own browser after reporting a failed start, and both take the same fix: Restart now on the Browser did not start banner.

​
running_issue: the session dies right after starting

Restart once. A proxy error also marks the proxy dead and swaps in a replacement by itself. If the browser keeps flapping, it escalates.
Escalation is exact: more than 10 recorded failures and more than 10 error log rows in the last 48 hours moves the browser to client_error_investigation (the cause is yours to fix) or support_error_investigation (ours, or unclassified). The bound LinkedIn account is cascaded to sync_failed. A client parking emails the workspace owner (at most one per owner, per browser, per hour); a support parking pages our team instead. Recovery is manual: open the browser and look at it.
Identical log rows are collapsed: two events with the same browser and the same event_type inside 60 seconds produce one row, not two, so the log undercounts a rapidly flapping browser. The fail count on the browser block is the honest counter.

​
login_issue: LinkedIn asks to log in again

The drawer shows Signed out of LinkedIn. During an initial sync the sync box shows Sync paused, action needed, with browser:logged_out next to the Reason: label and the reason line LinkedIn session lost. That code is a fixed display string in the app, not the sync run’s wait_reason. There is no separate “logged out” status, and three properties of this one explain almost every ticket in this category:
  • It is sticky. Later runtime errors, proxy errors and repeat logout reports are recorded in the log but cannot reclassify the status or bump the counters. Only a successful re-login moves the row off it.
  • The browser is already powered off, which is why the row action reads Start rather than Restart.
  • Nothing will wake it. Automatic wake covers idle browsers only.
A logout is almost always noticed at the next start, not mid-run: the post-start check is what probes the LinkedIn session, so a session LinkedIn invalidated while the browser sat idle only surfaces when the browser comes back up.
The ACCOUNT row does not change when this happens: its status is platform lifecycle and keeps reading active while the browser sits in login_issue. Any health read, human or API, must look at the browser: over the API that is include[]=antidetect_browser on the account search, plus the always-present counts.signed_out_count (account health).
Two emails can follow a logout, and the platform decides which one before it sends anything. Right after the crossing it reads the member’s public profile from another LinkedIn account of the fleet, the way any visitor would. A profile that answers means a lost session: the person who connected the browser gets Your LinkedIn account was signed out, with a Profile check line saying the profile is still up. No profile for the member’s stable id means LinkedIn restricted the account (or the holder closed it): the browser moves to restricted and the mail is LinkedIn restricted your account, with LinkedIn’s verification and appeal steps instead of a re-login (see below). When the check itself cannot run, the plain signed-out mail goes out without the check line. The events go to analytics and to webhooks as antidetect-browsers.logged-out and, for the verdict, antidetect-browsers.restricted; on screen they are the two red pills. If you run many accounts, subscribe to those webhooks rather than waiting to be told.

​
Re-login is the only fix

Pressing Start re-verifies the session end to end rather than repairing it: either the session turns out intact and the browser recovers to running, or the login wall is hit again and the row goes straight back to login_issue with another power-off.
  1. In the account drawer, the red Signed out of LinkedIn banner sits above the tabs; click Log in via cloud browser there (the same link is on the account row). Connecting takes up to 30 seconds.
  2. Click Log into LinkedIn and complete the login in that window, including any verification LinkedIn asks for. You are typing into the account’s own browser, on its own proxy, so the device and location LinkedIn sees do not change.
  3. Click I have logged in and keep the window open while the profile uploads to secure storage. The upload is confirmed from the launcher log within about 90 seconds; the app then closes the window and watches the browser every 3 seconds for up to 4 minutes. Reaching running reports LinkedIn session restored, the browser is back up; hitting the 4-minute deadline reports Still verifying the session, we’ll keep working in the background.
Syncing and automations resume on their own once the browser is running again, from where they stopped. If the person who can pass LinkedIn’s verification is not a user of your workspace, issue a temporary link to the same browser session with antidetect-browsers/generate-cloud-browser-access-key. Call revoke-cloud-browser-access-key on the same sid first, so any older link dies.
A cloud-browser access key is a bearer secret: anyone holding the link can drive that browser. The default lifetime is 8 hours, ttl_hours accepts 1 to 720, and you can cap max_connects (1 to 1000) and restrict allowed_ips or allowed_countries. Without a cap the link is redeemable until it expires, so pass max_connects: 1 to make it single-use. Send it through a private channel and revoke it once the login is done.

​
restricted: LinkedIn took the account away

The drawer shows Restricted by LinkedIn in place of the signed-out banner, and the status popover names the verdict: LinkedIn has no public profile for this member, checked from another LinkedIn account right after the sign-out. That is what a restricted account looks like from the outside (a closed account looks the same, so if you closed it yourself this is a false alarm and a re-login clears it). The Browser event log carries an account_restricted row with the identities that were asked and LinkedIn’s answer. Three things follow from the verdict:
  • A re-login alone will not fix it. Pressing Start re-verifies the session, hits the login wall again, and the probe runs again: the row lands back on restricted.
  • LinkedIn is the only place to lift it. Sign in to LinkedIn on your usual device or browser, not through the cloud browser: LinkedIn shows the restriction notice and the steps it wants, usually a photo ID check, sometimes an appeal form through LinkedIn Help. Most temporary restrictions clear within a few days once the steps are done. Until then, do not run the account from another tool: every new sign-in attempt counts against it.
  • Then re-login here. Once LinkedIn lets you in, follow the re-login steps exactly as for login_issue; the account picks up where it stopped, and nothing is lost in the meantime.
Over the API, a dispatch on a restricted sender is refused with HTTP 409 and error.context.reason = "browser_account_restricted" (the logged-out refusal reads browser_logged_out), and the account search’s counts.restricted_count says how many senders sit there; counts.signed_out_count counts both red statuses.

​
Read the event log

The Browser event log lists When, Level, event type, Code and Message. The rows that matter: Most rows carry no code at all, so filter on event_type and read the cause out of the message rather than the code column. The same log is searchable over the API. counts.groups.event_type and counts.groups.code answer “logged out, or proxy, or runtime” on their own, so ask for page_size: 0 when you do not need the rows themselves.
curl

​
Restart over the API

POST /linkedin/v4/api/antidetect-browsers/run with {"sid": "ab_br_..."} is the same action as Restart now. It is accepted from stopped, idle, start_issue, running_issue, login_issue, restricted, client_error_investigation, support_error_investigation and maintenance. Every refusal returns HTTP 409 with error.code = "conflict", so switch on error.context.reason, never on the code alone. Two more come from action endpoints rather than from run: HTTP 503 with recoverable: true means the session is not alive and the action should be retried after a restart, and HTTP 409 with reason captcha_required or account_soft_locked means LinkedIn wants a human in the browser first. Full request shapes are in the API reference.
Copyable prompt for your own agent:“Triage a stuck LinkedIn account for me using the GTM API. Find the account’s antidetect browser and read its status. If the status is login_issue, stop and tell me to re-login through the cloud browser; do not call run. If it is start_issue or running_issue, search antidetect-browser-logs for that browser sid with level error over the last 24 hours, sorted by created_at descending, and report the newest event_type, code and message. Then call run once and report the resulting status. If run returns 409, print error.context.reason verbatim and stop.”

​
Still stuck

Send us the account name and the browser sid (ab_br_..., on the Browser tab), a screenshot of the drawer showing the status pill and the banner text, and the newest error row from the event log verbatim: event type, code and the full message string.