Design Maintenance and Degraded Modes

Performance & Reliability · errors, status, trust

Updated 2026-07-28

Plan the bad day before it arrives. Maintenance pages and degraded modes are always written under pressure unless they were designed calmly in advance.
Prefer degrading to going dark. Read-only access, cached data, and a subset of features are far better than a locked door for most incidents.
Say clearly what still works and what does not. Users will keep trying the broken thing until you tell them it is the broken thing.
Give a time, even a rough one, and update it. "Back around 14:00 UTC, next update at 13:30" prevents the refresh loop that a silent page creates.
Protect work in progress. If a save will fail, say so before the user writes for ten minutes, and keep a local draft they can recover.
Take the pressure off support. Link to a status page, state whether anything needs to be reported, and say what will happen to work that failed.
Restore quietly and completely. When the system recovers, retry queued work where it is safe, tell the user what succeeded, and clear the banner.
Never leave the maintenance state on after the fact. A stale warning is the fastest way to lose the credibility the honest one just earned.

Users judge reliability by how a product behaves when it is broken, not by how it behaves when everything works.