What does ONLINE mean on the Nodetonet device panel?

ONLINE means all three internal checks have passed: the agent sent a heartbeat within the last 90 seconds, the WebSocket control channel is open, and no IP rotation is currently in progress. The device is ready to handle proxy traffic immediately.

What is the difference between IDLE and OFFLINE?

IDLE means the WebSocket is still open but heartbeats have not arrived for 90–300 seconds — the device is probably transitioning between networks and will likely recover on its own. OFFLINE means the WebSocket has dropped or heartbeats have been missing for more than 5 minutes; the device is unreachable and no traffic is routed to it.

Does my proxy stop working when the device is OFFLINE?

Yes, the proxy returns a 503 Service Unavailable error when all of its tokens are OFFLINE. However, no balance is consumed in this state. As soon as one device comes back online, the proxy resumes serving traffic. Adding a second device to the token group eliminates this single point of failure.

Why does my device show ERROR and what should I do?

ERROR means the agent app itself sent a fault message — not a connectivity problem but an internal error. Hover over the badge to read the message. The three most common fixes are: re-pair the token if it was regenerated, update the agent app if there is a version mismatch, or re-grant the network/VPN permission in Android settings.

Why does my device badge flicker between ONLINE and IDLE?

Flickering usually means heartbeats are arriving inconsistently, not that the device is broken. Common causes are carrier deep-packet inspection on busy cells, captive portals that interrupt the persistent TCP connection, or intermittent mobile signal. The proxy still works during brief IDLE windows, but adding a second device to the token group ensures the pool stays available even when one badge wobbles. See token groups: creating device pools for setup guidance.

How often is the device status refreshed in the panel?

The status badge is recomputed every 5 seconds. The agent sends a heartbeat every 25 seconds, so there is a brief window between agent pings where the displayed status reflects the last known values. In practice this means a device that just came online will turn green within 5 seconds of its first heartbeat arriving.

What ONLINE actually means — device health, decoded

Every device row in the Nodetonet panel wears one of four status badges: ONLINE, IDLE, OFFLINE, or ERROR. The colours look self-explanatory, but the exact rules behind them — and the difference between IDLE and OFFLINE — are what determine whether your proxy is actually serving traffic right now. This guide decodes each badge, explains the three internal signals that drive them, and shows you how to interpret and fix unusual states.

TL;DR: ONLINE means all three checks pass and traffic flows right now; IDLE is a grace period; OFFLINE means the device is gone; ERROR means the agent itself reported a fault. Badges refresh every 5 seconds.

The three signals behind every badge

Before looking at each badge individually, it helps to understand what the panel actually measures. Behind every paired device the platform tracks three real-time values:

Last heartbeat timestamp — the wall-clock time the most recent ping arrived from the Android agent app. The agent sends a heartbeat every 25 seconds over the persistent WebSocket connection. If your network drops a packet, the clock just advances without an update.
WebSocket connection state — whether the bidirectional control channel between the agent and the platform's edge server is currently open at the TCP level. This is a hard fact, not derived from heartbeats — a socket can be open while heartbeats are delayed, or closed while a stale heartbeat sits in the cache.
Pending IP-reset flag — a boolean that is true while an IP rotation has been requested but the device has not yet confirmed the new public IP. This flag clears in roughly 5–20 seconds depending on carrier re-attachment speed. During this window the device is technically healthy but its IP is in flux.

The status badge is a deterministic function of those three values, recomputed every 5 seconds. Nothing else influences it — not CPU, not battery, not your data quota.

Status badge reference

The table below gives the exact rule for each badge so you can predict what the panel will show for any combination of signal values:

Badge	WebSocket	Last heartbeat age	IP reset pending	Will route traffic?
ONLINE	Open	Under 90 s	No	Yes — immediately
IDLE	Open	90 – 300 s	No	Skipped in pools; tried if sole device
OFFLINE	Closed — OR — heartbeat older than 300 s	Over 300 s (if socket still open)	Either	No
ERROR	Open (agent connected)	Recent	Either	No — agent reported an internal fault

ONLINE — the healthy state

All three checks pass: the heartbeat arrived within the last 90 seconds, the WebSocket is open, and there is no pending IP reset. The device will accept a proxy request right now. On a properly configured Android phone paired with the Nodetonet agent — see your first token and Android pairing — you will see this green badge almost all the time.

A device that has been ONLINE continuously for several hours is reliable infrastructure. You can safely pin a long-running scraper to it, point a browser at it, or put it in a token group pool as a trusted member. Requests are routed to ONLINE devices first in round-robin selection.

IDLE — the grace period

The WebSocket is still open and no IP reset is pending, but the last heartbeat arrived between 90 and 300 seconds ago. This is an in-between state: the platform has not given up on the device, but it has missed several heartbeats and a request sent right now might time out before the agent responds.

IDLE happens on healthy devices more often than you would expect. The most common causes:

The phone switched from Wi-Fi to cellular (or back) and is renegotiating the network interface — typically resolves in under a minute.
A cell-tower handoff caused a brief OS-level network interface change.
Android's Doze mode batched background activity and delayed the heartbeat — see Android agent troubleshooting for how to exempt the agent from battery optimisation.
The carrier's deep-packet inspection is throttling or delaying the persistent TCP connection on a busy cell.

IDLE devices almost always recover by themselves. The panel skips IDLE devices when selecting from a token group — round-robin advances to the next ONLINE member. The exception: if the IDLE device is the only token behind a proxy, the platform will still try it and let your client observe the actual timeout rather than returning an immediate error.

OFFLINE — the device is gone

Either the WebSocket has closed, or the heartbeat has not arrived in more than 300 seconds (5 minutes). The device is not reachable and the platform will not attempt to route traffic to it.

Proxies whose only tokens are OFFLINE continue to exist in the panel but return 503 Service Unavailable on every request until at least one device comes back online. Crucially, no balance is consumed while in this state — you pay for proxy-seconds only while at least one routable device is behind the proxy.

The most common causes of OFFLINE are phone being powered off, the agent app being force-stopped by the user or by Android's background-process management, or a complete carrier network outage. If a device is showing OFFLINE unexpectedly, check whether the agent app is still running in the foreground or in a persistent background service. The Android troubleshooting guide covers the full checklist.

ERROR — the agent reported a fault

This is the rarest badge. The WebSocket is open and the agent is communicating, but the agent itself has sent a fault report — not a missing heartbeat, but an explicit error message. Common causes:

Bad or revoked token — the token paired with this device was deleted or regenerated in the panel after pairing.
App version mismatch — a schema change in a recent platform release is not handled by an outdated agent build. Update the agent app to clear this.
OS network permission revoked — Android revoked the VPN or network-access permission the agent needs to proxy traffic.

ERROR almost always requires human intervention. The agent has stopped retrying on its own because retrying would not help — fix the root cause (re-pair the token, update the app, re-grant the permission), then restart the agent.

Hover over the ERROR badge in the panel to read the agent's last fault message — it pinpoints which of the three causes above applies.

Why does the badge sometimes flicker?

A device that cycles ONLINE → IDLE → ONLINE every minute or two is reaching the platform, but its heartbeats are arriving inconsistently. This pattern — sometimes called heartbeat jitter — is almost always caused by network infrastructure between the phone and the edge server, not by the agent itself:

Carrier DPI on busy cells — some mobile operators inspect persistent TCP connections and introduce artificial delays or mid-session resets during peak hours.
Captive portals — corporate or hotel Wi-Fi networks that intercept TCP before re-authentication interrupt heartbeat delivery.
Intermittent signal — a phone on the edge of coverage drops packets sporadically but does not fully disconnect.

During brief IDLE windows, your proxy still technically works — it is just that token group round-robin skips that member for a few seconds. If the flicker is affecting real traffic, the most reliable fix is to add a second device to the same token group: round-robin keeps the proxy serving even while one badge wobbles. This is exactly what the pool design in token groups: creating device pools is built for.

The IP-reset pending state

When you trigger an IP rotation — either manually from the panel or via the API — the platform sends a rotation command to the agent, which triggers an airplane-mode cycle or equivalent carrier re-attachment. During those 5–20 seconds the device is still ONLINE (heartbeats continue) but the pending-IP-reset flag is set. The panel shows a spinner or rotation indicator; the device is not routed until the new IP is confirmed. This is by design: sending a request to a device mid-rotation would risk it arriving on the old IP and being rejected by the carrier.

If the flag stays set for more than about 60 seconds, the carrier is taking unusually long to reassign an IP. This can happen on crowded cells or certain MVNO configurations. In those cases, triggering another rotation usually resolves it. See when to use rotating mobile proxies for guidance on rotation frequency and best practices.

Monitoring device health programmatically

The badge you see in the panel is also queryable via the REST API: the device status field mirrors the same ONLINE / IDLE / OFFLINE / ERROR values shown in the UI. You can poll it to build your own alerting, or use webhooks to receive a push notification whenever a device transitions to OFFLINE. Both approaches are covered in monitoring your proxy and tunnel health. For a detailed look at how the platform decides which device to pick from a pool each time, see how round-robin device selection works.

Quick-fix checklist

IDLE badge, device feels healthy — wait 60 seconds; it usually flips back. If not, check Wi-Fi/cellular transitions and Android Doze exemption.
OFFLINE, phone is on — confirm the agent app is running; restart it if needed. Check battery-optimisation settings — many Android OEMs kill background apps aggressively.
OFFLINE, proxy returns 503 — normal behaviour; no balance is burned. Bring the device back online or add a second device.
ERROR badge — hover for the fault message; re-pair the token, update the app, or re-grant network permissions as directed.
Persistent flicker (ONLINE/IDLE cycle) — add a second device to the token group so pool availability is maintained while one badge wobbles.

For device setup from scratch, see installing the Nodetonet agent and your first token and Android pairing. Ready to start? Create a free account and pair your first device in minutes.