Denial of service is the lasting operational condition in which a system is unavailable to the people meant to use it daily.
The condition describes the outcome, and it can follow a fault, a capacity mistake, or a hostile act.
How it works
Users experience errors, timeouts, or a silent service, regardless of whether the cause is an overload, a failed dependency, or a deliberate attempt.
Naming the condition helps incident bridges talk about impact before they have agreed on the cause.
A many source flood is only one route to this condition, and a single deliberate attempt is another.
Recovery still means restoring the service people need, communicating impact honestly, and only then assigning the cause to the right later review.
Concrete examples
- A scheduling site shows errors all morning because a dependency failed, and patients cannot book even though nobody is attacking it.
- A payroll portal is unreachable during peak hour after a capacity change that was too small for the load.
- A public form stops accepting submissions while operators still do not know whether the cause is hostile or internal.
Protective measures
- Define what unavailable means for each essential service, including the user visible sign you will trust.
- Prepare a status message that states impact and the next update time without guessing a cause you have not confirmed.
- Keep a dependency map so a failed partner service is visible as a possible reason for the condition.
- After restoration, record whether the condition came from a fault, a capacity gap, or a hostile act, and track that separately.