> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gtm-api.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Browser will not start
> The antidetect browser sits in an issue status, the session dies right after starting, or LinkedIn keeps asking to log in. How to read the status, what the platform already did on its own, and when re-login is the only fix.
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.
| Status | Pill | What happened | What clears it |
| - | - | - | - |
| `start_issue` | amber | The launch was reported as failed. The browser is not running. | Run it again |
| `running_issue` | amber | The session started, then hit a runtime or proxy error. Powered off. | Run it again, then check the proxy |
| `client_error_investigation` | amber | Repeated failures crossed the escalation threshold on a cause only you can fix: the vendor profile was deleted, the LinkedIn session or account is the problem, or the proxy you supplied is down. Powered off. | Fix what **Last error** names, then Restart |
| `support_error_investigation` | amber | Repeated failures crossed the threshold on our side (a pool proxy, the node, the host) or on a cause we could not classify. Powered off. | Nothing on your side: our team is paged and restarts it once the cause is cleared |
| `login_issue` | red | LinkedIn invalidated the session. Powered off, and sticky. Right after the logout the platform checked the account from another LinkedIn account and the profile was still up, so this is a lost session. | Re-login inside the browser, nothing else |
| `restricted` | red | LinkedIn invalidated the session and, checked right after from another LinkedIn account, shows no public profile for the member: a restricted (or closed) account. Powered off, and sticky. | Sort it out with LinkedIn on your own device (its verification or appeal), then re-login inside the browser |
| `shared_out` | grey | Not a fault. The browser is lent to another workspace. | The share ending |
| `subscription_required` | amber | Not a fault. The browser does not fit the team's subscription. | Upgrading, or freeing a slot |
`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
| Behaviour | Exact rule |
| - | - |
| Auto-suspend | A `running` browser with no activity for 15 minutes is powered off and committed as `idle`. The reaper runs every 1 minute. |
| Wake on demand | Only an `idle` browser wakes by itself. An action waits for it to come up; a due sync defers and resumes. See [sync windows and auto-suspend](/kb/sync-windows-and-auto-suspend). |
| Power-off on fault | Landing in `running_issue` or either `error_investigation` status triggers a best-effort stop of the session. The stored status stays at the fault value so you can still see it. |
| Power-off on logout | The `login_issue` branch tears the session down immediately, and the row stays `login_issue`. |
| Proxy fault | A proxy error marks the proxy as `no_connect` and migrates the browser onto a fresh proxy in the same country. The browser's fail count is not incremented, because the proxy was at fault. |
| Sync backoff | A sync run that cannot reach the browser stays `in_progress` and re-checks. No data is lost and the cursor does not move. |
| Profile survives | Powering off a faulted browser does not log the account out. The profile persists on disk, so the LinkedIn session survives a power-off, a suspend and a cold start. |
`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](#re-login-is-the-only-fix); restarting it will not help. `restricted` goes to
[LinkedIn first](#restricted-linkedin-took-the-account-away): 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](/kb/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](/kb/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](#restricted-linkedin-took-the-account-away)). 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](/guides/receive-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](#re-login-is-the-only-fix) 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:
| `event_type` | `code` | Means |
| - | - | - |
| `start_failure` | `null`, or the HTTP status of the failed start dispatch | The launch was reported as failed |
| `login_issue` | `401`, or `null` when the logout was seen as an authwall redirect | LinkedIn logged the session out |
| `proxy_error` | `null` | The proxy did not answer; a replacement is being attached |
| `runtime_error` | `null` | The session broke after starting |
| `server_unreachable` | `777` | The automation server hosting the browser went unreachable |
| `error_escalation` | none | The threshold tripped, status moved to `client_` or `support_error_investigation` |
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.
```bash curl theme={null}
curl -X POST "https://app.gtm-api.com/linkedin/v4/api/antidetect-browser-logs/search" \
-H "Authorization: Bearer gtm_live_YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{
"filter": {
"antidetect_browser_sid": {"eq": "ab_br_Hx7kQ3mN2pL4"},
"level": {"eq": "error"}, "created_at": {"gte": "2026-08-12T00:00:00Z"}
},
"sort": {"field": "created_at", "direction": "desc"}, "page_size": 50
}'
```
## 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.
| `error.context.reason` | Meaning |
| - | - |
| `invalid_status_transition` | A status `run` does not accept, for example a HOLD state. `context.from` carries it |
| `vendor_profile_busy` | Another row is already running this browser profile |
| `no_automation_server_available` | No healthy host to launch on. Retry later |
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](/api-reference/overview).
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.
## Related
* [Antidetect browsers and proxies](/kb/antidetect-browsers-and-proxies)
* [Connect a LinkedIn account](/kb/connect-a-linkedin-account)
* [Sync windows and auto-suspend](/kb/sync-windows-and-auto-suspend)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.