How we detect outages
Our main source is user reports, complemented — when available — by additional technical checks.
1. Community reports
Any visitor can report a problem using the button on every service page. Each report is immediately:
- timestamped to the second;
- located by city using Vercel's IP headers, without ever storing the IP address;
- classified by symptom: login, payments, video, authentication, sync, app crash, notifications;
- for telecom operators, split between fixed line and mobile network.
This data is the primary basis of our analysis: it is aggregated into hourly buckets and kept to build a historical baseline.
2. Automated pings (technical monitoring)
Alongside reports, when enabled, technical checks can verify service availability through HTTP requests. This is an additional signal: at launch, status relies primarily on user reports. When technical checks are active, for a given service we may collect:
- the HTTP status code returned (200, 503, timeout…);
- the response latency in milliseconds;
- any error message.
Pings alone never raise a public alert: they reinforce or confirm what community reports already indicate.
3. Official status pages
At launch, status relies primarily on user reports. For services that publish an official status page, once this integration is active, we may read their indicator. A firm rule applies: an HTTP error or an unexpected indicator from the official API will never raise an alert; only a valid response with a status explicitly different from “all operational” is taken into account, to guarantee zero false positives caused by unreachable endpoints.
4. The algorithm — Outage Index
To keep an isolated report from triggering a false alarm, we compare the volume of reports over the last 2 hours against an adaptive baselinecomputed from the service's history.
history2hAvg = totalReports / hourlyBuckets
baseline = MAX(history2hAvg × 1.5, 12)
ratio = reports2h / baseline
scoreVolume = MAX(0, MIN(7.0, (ratio − 1) × 2.0))
scoreImpact = degraded × 1.0 + severe × 2.5
index = MIN(10.0, scoreVolume + scoreImpact)
The minimum noise threshold (here 12 reports) is deliberately kept low: on smaller or newly launched services, volume is lower, and a threshold set too high would hide real outages. The structure and transparency of the calculation stay the same.
The index maps to status levels: Operational, Minor issues, Moderate outage, Significant outage, Major outage (up to index 10).
5. Recovery and return to normal
A service returns to “Operational” once report volume drops below the baseline for long enough. In the hours following a significant outage, a heightened watch modestays active: the service remains under observation even after the index has already come back down.
6. Alerts
- Rising reports: a sudden spike triggers an internal check.
- Official status pages: once the integration is active, an incident confirmed by the provider can be taken into account right away.
7. Limits and transparency
servicedowntoday.com cannot detect every outage. Some remain hard to see:
- very local outages (a single city, a single operator, a personal network issue);
- subtle functional bugs affecting only a minority of users;
- services rarely searched on the platform, where the baseline is too thin.
Our data reflects activity observed on the platform and is not an exhaustive audit of the services' infrastructure. When in doubt, always check the service's official communication.
8. Anti-spam and GDPR
- One report per service per hour: the IP + User-Agent fingerprint is pseudonymized (salted SHA-256 hash) — no raw IP is ever stored.
- No tracking cookies on reports.
- Comments and report details are published at once if they pass an automatic filter (insults, slurs, threats, links and spam are hidden). E-mail addresses and phone numbers are masked, a comment is 5 to 280 characters, and the limit is 5 comments per hour. Anything published can be removed on report.
For details on how data is processed, see our privacy policy.