How We Detect Service Problems
The purpose of our methodology is to make the strength and limits of each status claim clear. A broad operational label should reflect recent corroborating evidence, not the absence of complaints. A narrow endpoint label can report one actual check without claiming that the whole service works or is down.
Independent technical checks
A separate Node.js worker runs on a schedule, independent of website page views. For configured, public HTTPS endpoints, it checks DNS lookup, TCP connectivity, TLS handshake, HTTPS response, and response time. These observations are stored with their timestamps. A response such as an access challenge may still show reachability, but it does not prove that every app feature works.
The worker never logs in to private government portals or any third-party user account. It does not send transactions or read private data. Endpoint selection is intentionally conservative; a service without a safe configured endpoint remains partially or wholly unmonitored until an appropriate one is added.
Pakistan, global, and ISP-level signals
RIPE Atlas can provide probe observations from multiple networks when suitable public measurements are configured for the service. We require several recent probes across more than one network before calculating a Pakistan or international availability estimate. An individual failed probe may have its own connectivity issue and cannot establish a national incident.
OONI data may show unusual failures from Pakistan, but measurement coverage depends on volunteers, networks, and timing. An anomaly is not proof of censorship or deliberate blocking. We use it as context that must be corroborated. Network-level labels also require enough recent samples; otherwise the UI says insufficient data.
Official provider sources
A provider's public status feed can be an independent signal for incidents it acknowledges. Such feeds may cover several products, update after users first notice a problem, or omit a local access issue. We therefore show them alongside other observations rather than treating them as a perfect answer.
Classification and confidence
The classifier uses a recent evidence window and treats direct checks, Atlas measurements, OONI observations, official feeds as different signal families. One fresh successful Pakistan check can show “working fine in Pakistan”. When regional measurements are missing, one successful public website check can supply a working display for Pakistan or Worldwide. Supporting text identifies the monitoring-location basis and the lack of verified local coverage. Stored regional measurements remain separate. Restricted checks are labeled separately. Broad operational and outage classifications require independent sources, and geographic claims require appropriate probe coverage. Mixed evidence may produce possible problems; multiple elevated sources can support a stronger disruption label. A Pakistan-specific label requires local failures while broader independent observations appear normal.
High, medium, and low confidence describe how much independent evidence contributed. A provider timeout supplies no positive signal. Stored assessments become stale after a short period without fresh checks, at which point the page returns to insufficient evidence. Thresholds are configurable in the worker environment and can be adjusted as coverage improves. No status engine can guarantee perfect knowledge of every user's connection.
History, retention, and corrections
Recent raw checks are retained for a limited period, then summarized into hourly aggregates. The default raw-check retention is 14 days. Hourly aggregates and incident records support longer historical views without retaining every raw check forever. A 7-, 30-, or 90-day chart remains empty when the needed observations do not exist.
If an automatic classification conflicts with strong evidence, we review the source data and the affected scope. We do not retroactively invent incident updates or statistics. Readers can request a correction using the Contact page; an account-specific problem should still be taken to the relevant provider.