Reliability work
Availability checks
A practical outside-in review of the public paths people rely on first.
What this covers
- Public entry points and important inner paths.
- Certificate, DNS, and asset checks that affect real visitors.
- A short written result that can be compared after the next change.
Start from the public edge
Availability checks begin with what a visitor can reach from outside. That means the home page, important public paths, static assets, certificate details, and one or two paths that matter to the service owner.
The point is not to create a large monitoring program. The point is to confirm that the visible surface still behaves as expected, especially after routine updates, DNS changes, or certificate renewal work.
Keep the scope readable
Small teams often stop using checklists when they become too broad. A useful availability review stays narrow enough to repeat. It should say what was checked, what looked normal, and what should be reviewed again later.
The most useful notes include exact paths, expected status codes, and the resolver or browser used for the check. That makes the result easier to compare when another person repeats the work.
Make the result useful later
A good availability note is written for the next maintenance window. It records the current public behavior, not just that a command finished successfully.
If a path is slow, missing an asset, or returning an unexpected response, the note should separate the visible symptom from the suspected cause. That keeps follow-up work calm and specific.
Typical review list
- Open the home page and one important inner page from a clean browser session.
- Confirm expected status codes, page titles, and visible page content.
- Check that stylesheet, image, and icon assets return successfully.
- Confirm certificate expiry and name coverage for active public names.
- Record the final observation in plain language.