The check interval controls when monitoring is scheduled. It does not control how often the browser redraws the dashboard.
The customer dashboard refreshes monitoring data approximately every 60 seconds while the page is visible and the browser is online. A completed check can therefore appear after its request finishes, its result is saved, and the next dashboard refresh occurs.
Why the displayed time can lag behind
A check passes through several steps:
- The scheduler identifies a due monitor.
- The check waits briefly for available processing capacity.
- The website request runs for up to the configured timeout.
- A failed primary request can start confirmation checks in additional regions.
- The result and any status or incident change are saved.
- The dashboard requests the latest snapshot and updates only changed monitor cards.
A fast successful check usually completes sooner than a timeout or a region-confirmed failure. A one-minute monitor may therefore show a check timestamp that is older than one minute without indicating that monitoring has stopped.
Read the Last update indicator
The dashboard's Last update indicator describes the age of the newest monitoring data represented by the dashboard. It is not a countdown to the next check.
- A recent value means the dashboard is receiving current data.
- The indicator receives a warning style after the represented data is more than 10 minutes old.
- Pending means no dashboard snapshot has been loaded yet.
The dashboard can display a recent cached snapshot immediately while it checks for newer information. Cached dashboard data is used only as a short loading optimization and is refreshed from the authenticated API.
Automatic refresh behavior
- The normal refresh target is approximately 60 seconds.
- Leaving the tab hidden pauses its refresh timer; returning to it requests an update promptly.
- Going offline pauses refreshes; reconnecting requests an update.
- Multiple open dashboard tabs coordinate polling to avoid sending unnecessary duplicate requests.
- If a refresh request fails, retries slow down temporarily instead of repeatedly overloading the service. The delay can increase to several minutes until a request succeeds.
The page keeps existing monitor cards visible during background refreshes and replaces only cards whose displayed data changed.
Compare the dashboard with Monitor Details
When one card appears delayed:
- Open that monitor.
- Compare Last checked with the dashboard's Last update value.
- Open Detailed Logs and check the newest row.
- Confirm the monitor is Active and review any automatic-protection notice.
If Detailed Logs contain a newer result, monitoring completed and the issue is limited to the dashboard view. Allow the next refresh or reload the dashboard once.
If Detailed Logs are also missing expected rows, troubleshoot the monitor schedule or processing instead of the dashboard display.
Changes made from another page
Creating, pausing, activating, or deleting a monitor can update the dashboard immediately using a temporary local state. The next authenticated dashboard response confirms the server state.
If the action remains different after the next refresh, open Monitor Details to confirm the saved setting. Avoid pressing an action repeatedly while the original request is still processing.
Troubleshooting a stale dashboard
- Check that the browser is online.
- Return to the dashboard tab and wait for one refresh cycle.
- Check the Last update indicator for a warning.
- Close unnecessary duplicate dashboard tabs.
- Open Monitor Details and Detailed Logs to determine whether monitoring itself is current.
- Reload the dashboard once if the API data is current but the card is not.
- Check any service notice displayed at the top of the dashboard.
Signing out, clearing all browser storage, or recreating a monitor should not be the first response to a delayed card. Those actions can interrupt your workflow without correcting server-side processing.
When to contact Support
Contact Support if Last update remains more than 10 minutes old while your connection is working, or if an Active monitor misses multiple expected checks.
Include the monitor name, URL, interval, newest Detailed Logs timestamp, dashboard Last update value, and approximate time the delay began. Do not include credentials, verification codes, or secret request headers.