How Sentinel works
TrustedStatus Sentinel publishes an independent view of service reliability from a UK probe node. The aim is simple: a calm, factual answer to the question, “is this a real issue, or just me?”
Sentinel does not treat vendor status pages, social chatter, or isolated user reports as ground truth. It publishes what the node can actually observe, then applies validation rules to reduce false alarms and noisy status changes.
Automated checks from a regional probe node, not crowd-sourced reporting.
Consecutive-run logic helps avoid bouncing between states because of short-lived blips.
Recent status history helps users see whether an issue is isolated, emerging, or recovering.
What “independent” means
Sentinel runs lightweight, automated checks from its own UK node and publishes the observed result. It is designed to answer a very specific question: whether a service appears reachable and healthy from this monitoring viewpoint.
Vendor incident feeds can still be useful context, but they are not treated as ground truth. A vendor may report an issue that is limited by feature, geography, or account type. Equally, a service can look unhealthy from the node before a public incident page is updated.
What Sentinel measures
- Front-door reachability: whether the service responds at all from the UK node.
- Repeated degradation signals: patterns such as rate limiting, partial impairment, or repeated error responses where applicable.
- Consistency over time: Sentinel looks for repeated evidence before changing published status.
- Historical pattern: recent timeline data helps distinguish a one-off blip from a developing incident or a recovery phase.
How status decisions are made
Each probe run produces evidence. That evidence is then interpreted through Sentinel’s state logic rather than published raw. This is important because single-run results can be noisy.
- Operational means the service is responding normally from the node based on repeated healthy evidence.
- Degraded means the service is reachable but appears impaired, unstable, or repeatedly returning concerning signals.
- Outage is reserved for repeated true unreachability, such as timeouts, connection failures, or other hard access failures.
- Maintenance is typically derived from vendor signals or known maintenance windows and is prioritised over probe-based classification when active.
Consecutive-run validation (anti-flap)
Sentinel runs checks every minute, but it does not immediately switch status on a single bad result. It requires repeated evidence before changing what is published.
- Degraded: typically requires consecutive degraded evidence before the state is published.
- Outage: typically requires consecutive unreachable results before Sentinel declares a full outage.
- Recovery: also requires repeated healthy evidence so the service does not bounce straight back on a single good response.
This approach helps reduce false alerts from transient network noise, brief upstream blips, or one-off failures.
How HTTP 4xx and 429 responses are handled
A 4xx response usually proves the service is reachable, even if the request itself was blocked, rejected, or rate-limited. Sentinel therefore treats these as reachability-positive signals.
- HTTP 429: treated as reachable. If it repeats across consecutive runs, the service may be marked Degraded.
- 4xx never creates Outage: outage is reserved for repeated true unreachability.
Confidence and history
Sentinel is designed to show more than a single point-in-time label. Recent history provides context around whether a service has been stable, intermittently impaired, or recovering.
Confidence should be read as a signal of how strongly the recent evidence supports the published state. It is not a promise that every feature is working end-to-end, but it does help users judge how settled or noisy the current picture is.
What Sentinel does not claim
- It does not guarantee message delivery, call quality, login success, or every feature working end-to-end.
- It does not claim to represent every geography, ISP path, or user account condition.
- It is not a mirror of vendor incident pages.
- It is an independently observed view from the current monitoring node.
Current scope and limitations
- Internet routing and regional infrastructure vary. A problem in one area may not affect everyone.
- The current published view is based on a UK node perspective.
- Automated checks are intentionally lightweight and respectful of the monitored services.
- Additional nodes and broader regional coverage may be added over time.
Status definitions
See it in practice
Sentinel publishes not just a current state, but a recent history of behaviour. This helps distinguish between a one-off blip, a developing incident, and a recovery.
© 2026 ExieLabs Limited