A relevant public signal is associated with the affected service.
Methodology
From scattered signals
to a clearer incident.
ServiceIsDown brings public service-status information into one structured view. Our methodology is designed to keep the source visible, preserve the incident timeline and make uncertainty explicit.
The objective is not to replace official status pages. It is to make information from multiple services easier to discover, compare and understand.
01Collect
Find relevant public service-status signals.
02Normalize
Turn different source formats into a consistent structure.
03Connect
Associate updates with the right service and incident.
04Present
Show source, chronology, status and context together.
01
Source collection
Start with the source.
Incident intelligence is only useful when users can understand where the underlying information came from.
SignalWhat it contributesRole
Official status pages
Provider-published service health and incident information.
Primary
Incident updates
Changes in status, investigation, mitigation and resolution.
Timeline
Public service context
Service identity, category and relevant operational context.
Context
02
Normalization
Different sources. One incident structure.
Providers describe incidents in different ways. ServiceIsDown organizes those signals into a consistent model so users do not need to learn a new status format for every service.
SOURCE AInvestigating connectivity issues
SOURCE BElevated error rates
SOURCE CService degradation
SERVICEISDOWN
Structured incident
- Service
- Identified
- Status
- Normalized
- Timeline
- Preserved
- Source
- Visible
03
Incident timeline
The sequence matters.
A current status is only one point in an incident. The timeline helps show how the situation developed and separates earlier information from what is known now.
Subsequent source updates extend the chronology rather than replacing it.
Resolution is shown while the previous incident history remains available.
04
Certainty & interpretation
Facts should look like facts. Uncertainty should look uncertain.
ServiceIsDown should not make incomplete information appear more certain than it is. Source information, structured status and additional context need to remain distinguishable.
Users should be able to understand the origin of important incident information.
Missing or developing information should remain visibly incomplete.
Additional structure should help understanding without rewriting the underlying source.
05
What the status means
A status is a summary, not the whole story.
ServiceIsDown uses status information to make incidents easier to scan, while the source and timeline provide the detail needed to understand the situation.
Ongoing disruption
Current information indicates an active service problem.
Monitoring / developing
The incident remains active while new information or recovery is being observed.
Resolved
The available incident information indicates that the disruption has ended.
Status labels summarize the incident view presented by ServiceIsDown. For operational decisions, users should also review the linked source information and the latest provider update.
06
Principles
The methodology is built around four simple rules.
Keep the origin of incident information visible.
Show how information changed over time.
Make fragmented information easier to understand without hiding its source.
Do not turn incomplete information into false precision.
See it in practice
Methodology matters most when an incident is unfolding.
Explore current incidents and see how ServiceIsDown brings source information, updates and context into one view.
Explore incidents