Dashboard shows "Offline" behind a firewall or bot protection

If a dashboard works normally but shows that it is offline after a few quick filter changes (for example "Offline. You have unsaved changes. Wait until you're back online for your changes to be saved."), while every other website and your video calls carry on working, the cause is often a security layer in front of your Omniscope server. A web application firewall (WAF), bot protection, DDoS protection or a rate limiter can mistake a busy dashboard for an automated attack and start blocking it.

Why a dashboard can look like a bot

Report views fetch their data with ordinary HTTP requests. Each time a filter changes, every view on the page that needs data sends its own request, so a dashboard with many KPI tiles or charts can send 30 to 40 requests within a fraction of a second, and several quick clicks multiply that.

Some security products count requests per visitor. When the count passes their threshold, they stop passing requests to Omniscope and answer with a challenge instead: a page saying something like "One moment, while we check your browser...", a CAPTCHA, or a 403 or 429 error. A challenge needs a page that the browser displays and runs, so it works when a whole page loads but not for background data requests, which simply fail. Omniscope loses contact with the server and shows that it is offline until the security product lifts the block. Reloading the page may get you through the check, but the next burst of filter changes can trigger it again.

The blocked requests never reach Omniscope, so the server's own logs show nothing wrong. The security product's logs are the place to look, for example its firewall events for the user's IP address.

Checking whether this is the cause

• Try another network. As soon as the dashboard shows it is offline, open the same dashboard on a different connection, such as a phone on mobile data or a laptop on a phone hotspot. If it works there while your usual connection is still stuck, the Omniscope server is fine and something is blocking your usual connection. That is usually the security layer in front of the server, though a VPN or proxy on your own network can be the culprit too.
• Look at a HAR file. Capture one while reproducing the problem, following Diagnosing browser network issues (tick Preserve log in the Network tab first). Requests that normally return JSON data will instead return an HTML page, often a short one containing a script and "checking your browser" text, or a 403 or 429 status. If you're not sure, send us the HAR file privately, as it can contain session details.
• Ask who runs the infrastructure. The layer may belong to your hosting provider, your IT or security team, or a CDN in front of the site. People often don't know it is there, so ask "is there anything between users and the Omniscope server?" even if the answer you got before was no.

Fixing it

Ask whoever manages the security layer to exclude your Omniscope site from bot protection, browser checks and rate limiting. Excluding the whole hostname is simplest and covers every project and the admin pages. If they will only exclude specific paths, include each folder where your projects are published (for example /Sales/) and /_global_/, which Omniscope uses for shared resources. If your users connect from known office IP addresses, allowlisting those also works.

While you wait for the change, changing filter values more slowly, or selecting several values at once rather than one by one, usually avoids triggering the block.

Switching off the Enable WebSocket option in Admin doesn't help. The data requests above don't use the WebSocket, and without it the browser sends more HTTP requests, which makes the problem worse.

A related cause: connection timeouts

A proxy, load balancer or gateway in front of Omniscope can produce the same symptom by closing long-lived connections. Omniscope keeps a WebSocket connection open to exchange edits and updates with the server, and a request or idle timeout of around 20 seconds on the proxy will keep cutting it off. Make sure the proxy allows WebSocket connections and that its timeouts are at least 60 seconds.

Last updated on 6 November 2026