Latency Alerts & Thresholds: Warn, Down and Slow Limits
In Map and Monitor, each destination is judged against its own recent average: yellow above +40% and red above +70% by default, never for rises under 30 ms, and down when a request fails. Optional alerts show a toast and a short beep when a destination goes down or exceeds a time threshold (default 2000 ms), at most once every 30 seconds per destination. Every limit can be changed.
On this page
Quick answer: in the live modes, each destination is compared with its own recent average. If a reading is more than 40% above that average it turns yellow, more than 70% above it turns red, and a failed request is shown as down. A rise under 30 ms is ignored. If you enable alerts, GlobeLatency also shows a toast and plays a short beep when a destination goes down or becomes slower than your time threshold (default 2000 ms).
Two separate systems: state colours and alerts
It helps to separate what you see from what you are notified about:
| State colours | Alerts | |
|---|---|---|
| Purpose | Show how each destination compares with its own normal | Interrupt you about an important event |
| Based on | Percent above the destination's recent average | Down, or an absolute time threshold |
| Always on | Yes, in Map and Monitor | Optional |
| Output | Colours, cards, pins, state text | Toast message and a short beep |
How the state is calculated
- The engine keeps the last 60 readings per destination.
- A new reading is compared with the average of the earlier readings, provided there are at least three.
- If the new value exceeds the average by more than the yellow limit (default 40%) it is yellow; above the red limit (default 70%) it is red.
- If the increase is under 30 ms, the state stays normal regardless of percentage.
- If the request fails or times out it is down.
Yellow limit can be set from 10% to 100%, red limit from 20% to 200%. The timeout (default 5 seconds, range 1 to 15) decides when a request counts as failed.
Why the 30 ms guard?
On a fast link, a path that normally takes 10 ms can jump to 18 ms due to noise, which is +80%. Nobody feels 8 ms. The guard keeps the display calm so that colour changes represent changes you can notice. If you need maximum sensitivity, lower the percentage limits; the 30 ms guard still prevents trivially small changes from being flagged.
How alerts work
When alerts are enabled, an alert fires for a destination if it:
- goes down (no reply within the timeout), or
- exceeds the slow threshold in absolute milliseconds (default 2000 ms).
An alert shows a toast message with the destination name and reason, plus a short beep. To avoid floods, each destination alerts at most once every 30 seconds, even if it stays broken. Browsers may require a click on the page before sounds are allowed, which is why you should interact with the page after opening it.
Own limits per destination
In the detail panel of a pin or card, you can set a personal limit for that destination. It overrides the global threshold for that one host. Typical uses:
- a far or satellite-based server that naturally varies a lot: raise its limit so it stops crying wolf;
- a critical server you rely on: lower its limit to be warned earlier.
Choosing sensible values
| Situation | Suggested settings |
|---|---|
| Stable fibre or cable connection | Defaults (40% / 70%, 2000 ms) |
| Wi-Fi or mobile with natural variation | Yellow 60%, red 100% |
| Hunting short spikes | Interval 5 to 10 s, yellow 25% |
| Real-time use (calls, trading) | Alert threshold 300 to 500 ms for key destinations |
| Background watch | Alerts off, check the colours now and then |
Worked example
A destination has averaged 40 ms. A new reading arrives at 52 ms: +30%, below the 40% yellow limit, normal. Next, 66 ms: that is +65%, above both limits in percentage terms, but only 26 ms above the average, so the 30 ms guard keeps it normal. Then 85 ms: +112% and 45 ms above, so it is red. An alert is not sent because 85 ms is far below 2000 ms. Finally the destination fails: it turns down and, if alerts are on, a toast and beep fire once, and then at most every 30 seconds while it stays down.
What alerts cannot do
- They do not run when the tab is closed or the computer sleeps.
- They do not send email, SMS or push notifications.
- They detect problems from your location only; a server that is unreachable for you may be fine for others.
- Background tabs may delay checks because browsers throttle timers.
For 24/7 team monitoring from multiple locations, use a dedicated server-side monitoring service in addition to GlobeLatency.
Common mistakes and myths
- "Red should always beep." Red is a colour state; alerts have their own criteria.
- Setting the red limit below the yellow limit. Keep red above yellow.
- Too-aggressive intervals. Five-second checks on 40 destinations create many requests; use them briefly.
What to do next
See the cards in the Monitor guide, understand spikes in jitter explained, or if alerts do not behave as expected read Troubleshooting GlobeLatency.
Frequently asked questions
Why did I not get an alert even though a server was slow?
Alerts fire only when a destination goes down or crosses the slow threshold (default 2000 ms), and at most once every 30 seconds per destination. A server that is 80 percent slower than usual turns red but does not trigger an alert unless it also exceeds the threshold or fails.
Can I get alerts when the tab is closed?
No. GlobeLatency runs in your browser, so alerts work only while the Map or Monitor tab is open. It is not a server-side uptime service and it does not send emails or push notifications.
How do I stop the beeping?
Turn alerts off in settings, or raise the threshold. You can also set a higher own limit for a noisy destination so that it stops alerting while others still do.
What does a per-destination limit do?
It overrides the global thresholds for that destination only. It is useful for a naturally unstable server, such as a distant or mobile-network host, so it does not raise alerts that you consider normal.
Why must a destination have three readings before it is judged?
The comparison needs a baseline. With fewer than three earlier readings, the average would be unreliable, so the destination is shown neutral until enough data exists.