Darkmatter availability reports should separate ordinary maintenance, degraded access and wider service interruptions instead of treating every incident as a domain change.
Availability is an observation, not a diagnosis
When a Dark Matter mirror does not respond, the visible symptom may be a timeout, connection error or unusually slow response. Those symptoms can have several causes. A responsible status page should separate what was observed from what has actually been confirmed.
Planned maintenance
Maintenance is a scheduled change intended to update or repair infrastructure. A useful maintenance notice includes the planned start, expected duration, affected components and a follow-up when work is complete. If no schedule was published, the page should avoid retroactively calling every outage “maintenance.”
Ordinary infrastructure faults
Hosting failures, DNS problems, routing issues and configuration mistakes can make an address unavailable. These events may affect one destination while another remains reachable. The appropriate label is based on the observed impact, not an unsupported theory about the cause.
DDoS-related disruption
A distributed denial-of-service incident attempts to exhaust network or application resources with traffic. Symptoms may resemble other failures, so DDoS should be named only when the operator or monitoring evidence supports that explanation. Repeating “under DDoS” without evidence does not improve the status report.
What a professional incident update contains
- A specific publication and observation time.
- The affected address or component.
- The user-visible impact.
- Whether the cause is confirmed or still under investigation.
- The next scheduled update.
- A resolution note after normal availability returns.
Why multiple addresses need individual status
One Dark Matter URL can fail while a different address continues to respond. A status page should report each destination separately and should not transfer an “operational” label from one address to every mirror.
When a mirror change is announced
An outage creates urgency, which also creates an opportunity for misleading links to spread. A newly claimed mirror should go through the same source, destination and date checks described in the link verification guide. Availability pressure is not a reason to lower the verification standard.
After the incident
A brief incident history helps users understand what changed and prevents an old warning from being mistaken for a current event. The final entry should record when service returned and whether any published address changed.