A backup status page for your customers
Most hosting companies publish an uptime status page. Almost none publish the one customers care about after an incident: whether their data is backed up, how far back they can restore, and whether anyone has tested it. This guide covers what to put on such a page, what to keep off it, and how to keep it honest.
Why publish it at all
Every host's terms say something like "we back up daily". Customers can't check it, and they usually only ask after something has gone wrong, when the answer matters most and is hardest to give calmly.
A status page turns that sentence into something a customer can look at any day. It also changes the internal habit: a page that shows a failed night in red gets fixed faster than a log nobody reads.
What to show
| Item | Why it matters to a customer |
|---|---|
| Each backup tier | Local copy, offsite copy, immutable copy, offline copy: one line each. It shows that "backup" means more than one copy. Mapping the tiers to the 3-2-1-1-0 rule gives the page a structure people recognise. |
| Last successful run | A date and time per tier, not a green dot. "Last success 6 hours ago" means something; "OK" doesn't. |
| Restore depth | The oldest point each tier can restore to. Customers ask "can you get back last Tuesday's version?" more often than "do you have a backup?". |
| Last restore test | When someone last restored real data from that tier and it worked. A backup nobody has restored is a hope, not a backup. |
| Incident history | Failed or missed runs over the last 90 days, with how long it took to recover. This is the line that makes the rest believable. |
| Schedule | How often each tier runs, so customers can judge "last success" themselves. |
What to keep off it
A status page is public. Anything on it is information for an attacker as well as a customer:
- Hostnames, IP addresses and storage locations. "Offsite, different provider, different country" tells a customer enough. A bucket name or server address tells an attacker where to aim.
- Account names, domains and file lists. One customer must never be able to see another's data, even indirectly.
- Retention internals that weaken the immutable tier, such as which credentials can prune it or when.
- Raw logs and error messages. Summarise them: "upload to offsite failed, recovered next night".
Keeping it honest
- Generate it from the backups themselves. A page someone updates by hand drifts the first busy week. It should be built from what the jobs actually report, and go stale visibly if they stop reporting.
- Show missing runs, not just failed ones. A job that never started produces no error. If the page only reacts to errors, it stays green while nothing runs.
- Don't hide bad days. A page that has never shown a failure isn't believed. One that shows a failure and the recovery the next morning earns more trust than a perfect record.
- Time-stamp everything. "Updated 3 minutes ago" at the top tells the reader the page itself is alive.
One page, or one per customer?
| Scope | Shows | Suits |
|---|---|---|
| Server or service-wide | The state of each tier for the whole platform | Shared hosting, where every account is backed up the same way |
| Per customer | Only that customer's account: their runs, their restore depth, their incidents | Agencies, MSPs, and hosts with business clients who ask for proof in audits or questionnaires |
Many hosts will want both: a public platform page, and a private link per customer.
Checklist before you publish
- Every tier shows a last-success time, not just a colour.
- A job that stops reporting turns the page red within a day.
- Restore depth is shown per tier.
- The last restore test date is shown, and it's recent.
- Incidents from the last 90 days are listed with recovery times.
- No hostnames, IPs, bucket names, account names or file paths appear anywhere.
- The page shows when it was last updated.
How Servatum does it
Servatum builds this page from the backup jobs themselves and keeps it current: tiers, last success, restore depth, restore tests and incidents, on your own domain, with a JSON feed and a badge. Per-customer pages are planned for hosts and MSPs. It isn't live yet; the demo shows the layout with a real host's history.