Status Methodology

Our goal is simple: do not show outage labels without evidence. NepalStatus combines user reports, automated checks, official signals, and incident workflow before publishing a service state.

Evidence Sources

• User reports: report volume and unique reporters in the last 15 minutes.
• Automated checks: periodic HTTP checks for configured services.
• Official signals: provider updates and public statements.
• Incident state: active incidents created by admin or incident engine.
• Maintenance flag: planned maintenance published by admin or official signal.

Public Status Rules

• Checking: no reports and no strong check evidence yet.
• No current problems: no unusual reports and recent successful check evidence.
• Reports detected: early report cluster without failed checks.
• Possible problem: one failed or slow recent system check.
• Service disruption: repeated failed checks, many reports, active incident, or official outage signal.
• Under maintenance: active maintenance flag or official maintenance notice.

False Positive Protection

A single weak signal should not trigger outage mode. We explicitly guard against this:

• One failed probe usually maps to Possible problem, not Service disruption.
• HTTP 403 is treated as Inconclusive because some providers block bots.
• No evidence defaults to Checking rather than disruption labels.

Automation Schedule

Checks are run by cron workers and saved as evidence records. Service status is calculated from time-windowed evidence, not from manual guesswork.

Typical production schedule:

• bin/cron/check_services.php every 1 minute
• bin/cron/score_services.php every 2 minutes
• bin/cron/incidents.php every 2 minutes

Important Limitations

Some outages are local to a city, ISP, or account segment. A healthy global check does not guarantee every user is unaffected. We recommend reading service pages together with regional report patterns.