Troubleshooting
Guides for authoring, running and analysing tests across web automation, API and performance — plus setup, collaboration and release notes.
Network/connectivity checks
Connectivity problems usually affect the Local Agent link or outbound API requests. Work through these checks before deeper debugging.
Checks
- The Local Agent is running and the machine is reachable on the network.
- Required ports are open and not blocked by a firewall or VPN.
- For API Send, the endpoint URL, path, authentication, and headers are correct and reachable.
- Your browser allows the extension and any required permissions.
- You are connected to the internet for cloud runs and result sync.
Image placeholder — agent connectivity / network check
Local Agent connection (WebSocket, default port 8887)
Local AgentUI can't open the agent connection (local runs)
Local execution connects to the Local Agent over a WebSocket on your machine (default port 8887). If the connection never opens, the agent isn't running, isn't listening on the expected port, or the port is blocked. Start the agent, confirm it reports the WebSocket port on startup, and allow that port locally.
Local AgentAgent won't start: port already in use
If another process — or a second copy of the agent — already holds port 8887, the agent can't bind and the UI can't reach it. Close the duplicate agent or the conflicting app, or start the agent on a different port and use that port from the platform.
Local AgentFirewall, antivirus, or VPN blocks the local socket
Security software and some VPN clients block local WebSocket connections even though the agent is running. Add an exception for the agent's port, or temporarily disconnect the VPN, then reconnect from the platform.
Local AgentConnection drops during a run
If the machine sleeps or the network changes mid-run, the WebSocket closes and the local run is lost (local runs aren't persisted). Keep the machine awake for the run's duration, then reconnect the agent before retrying.
Live updates (SSE — results, metrics, notifications)
CloudLive results, metrics, or notifications stop updating
Live test results, performance metrics, and notifications stream over a Server-Sent Events (SSE) connection. If updates freeze, the SSE connection dropped — usually an expired session, a network blip, or a corporate proxy/ad-blocker that buffers or closes streaming responses. Refresh the page to re-establish the stream; sign in again if your session expired.
CloudUpdates arrive in bursts (proxy buffering)
Some proxies and SSL-inspection gateways buffer streamed data, so live updates appear in delayed bursts instead of continuously. Allow direct access to the platform domain, or use a network without stream buffering, for true real-time updates.
Platform & target-endpoint reachability
AllThe app fails to load data or sign-in requests fail
This points to the browser-to-platform connection: no internet, a firewall blocking the platform domain, or an SSL-inspection proxy breaking HTTPS. Verify connectivity to the platform URL and allow it through your network's security controls.
CloudCloud run can't reach a private/internal target
Cloud execution runs outside your network, so it cannot reach internal hosts, localhost, or VPN-only endpoints. Expose a reachable URL for the target, or run against it locally with the Local Agent.
APIDNS, certificate, or timeout errors against the target
When an API request fails to connect, check that the hostname resolves, the TLS certificate is trusted (no self-signed/expired cert), and the host responds within the timeout from the execution environment. Correct the endpoint or environment and re-run.
AllRequests start failing and live updates stop after a while
When your sign-in session (access token) expires, API requests begin returning authorization errors and the live results/metrics/notifications stream drops — tokens aren't renewed silently in the background. Sign in again to restore your session; both API access and live updates resume after re-authentication.
AccessLogin fails or never completes
Sign-in goes through a separate identity (OIDC) server. If the app loads but you can't log in, the authentication server or its endpoints may be blocked or unreachable from your network — this is a different dependency from the main app. Allow access to the identity server's URL through your firewall/proxy and retry.
Note:
If the agent is reachable but runs still fail, the issue is likely testcase or data related rather than connectivity — see .
Still stuck?
Run the , check the , or contact us at bitassert.com/contact.
