Status page vs changelog: what each one is for

Teams reach for a status page and a changelog at about the same stage — right after the first stranger depends on their product. The two get conflated because both are "public pages where we communicate about the product." But they answer different questions, run on different clocks, and mixing them makes both worse. This guide covers what each is for, when a small team actually needs a status page, and how the two should feed each other.

Two questions, two clocks

• A status page answers "is it working right now?" Its unit is the incident: detected, investigating, mitigated, resolved. Its clock is minutes. Users visit it mid-frustration, once or twice a year, and judge it on freshness — a status page 20 minutes behind reality is worse than none.
• A changelog answers "what has changed?" Its unit is the shipped change: dated, past tense, permanent. Its clock is days to weeks. Users visit it curious, not angry, and judge it on momentum and honesty.

The audiences overlap but the moods don't. Someone checking your status page during an outage does not want to scroll past "New: dark mode 🎉" to find out whether the API is down. Someone browsing your changelog doesn't want it dominated by "elevated error rates, resolved, 14 minutes" noise. One page cannot serve both moods.

Does your team need a status page yet?

Signals that you do:

• People page you when you're down. If an outage produces support messages within minutes, users need somewhere to look that isn't your inbox. "See status.example.com" ends ten identical threads at once.
• Other software depends on you. API consumers need a machine-checkable answer to "is it them or us?" before they wake their own on-call.
• You've promised uptime. The moment an SLA exists, you need a public incident history — it's the receipt for (or against) your own claims.

Signals that you don't, yet: nobody notices your outages but you; your product degrades gracefully offline; you have no paying or production-dependent users. In that stage a status page is theater — and a stale "all systems operational" page you forgot about during a real outage actively burns trust.

The one hard rule: separate infrastructure

A status page hosted on the same infrastructure as the product reports outages perfectly until the moment there is one. If your app is down and your status page is down with it, you've built a decoration. Host it anywhere that fails independently — a different provider, a different DNS zone if you can. This is also why "just add a banner to the app" is not incident communication: the app is exactly the thing that's unreachable.

Where teams go wrong merging the two

• Incidents in the changelog. Live-updating an entry ("investigating… update 14:32…") breaks the changelog's contract that entries are finished, dated facts. RSS subscribers get three edits of the same item; the archive fills with noise that buries real ships.
• Ships on the status page. Feature announcements next to uptime graphs read as clutter at best. During an incident they read as "they're shipping features while we're down."
• Neither, but a Twitter/Bluesky thread. Fine as a mirror, terrible as the system of record: unsearchable later, invisible to users who don't follow you, and dependent on a third party's uptime and login wall.

The loop: incidents end in the changelog

Separate pages, connected flow. The status page owns the incident while it's live; the changelog owns what the incident changed:

• During: all updates on the status page, minute-clock, in-place.
• After: if the incident led to real changes — a fix, a safeguard, a retry policy — that's a changelog entry like any other fix: "Fixed: background jobs no longer occasionally run twice", with a line linking the incident report for the curious.
• Postmortems live wherever the incident history lives (the status page), linked from the changelog entry — not pasted into it.

This is the trust-building move most teams skip: the status page proves you noticed; the changelog entry proves you changed something. (See how to write a changelog for phrasing fixes without weasel words.)

Planned maintenance: the one legitimate overlap

Scheduled downtime is genuinely both: a future status event and an announcement. Put the authoritative notice on the status page, and mirror it as an announcement-tagged changelog entry so feed subscribers hear about it on their own clock. Announce it before, not during — see announcing breaking changes for the same principle applied to API changes — and see the full playbook in scheduled maintenance announcements.

The changelog half, with Wakelog

Wakelog is the changelog side of this split: a free hosted changelog with a public page, RSS and JSON feeds, and webhook mirrors to Slack or Discord. Maintenance notices are entries tagged announcement, and scheduled publishing lets you write the notice today and have it publish on the maintenance date. Post-incident fixes are one command from your terminal:

wakelog post -t "Fixed: retries no longer double-send webhooks" -g fix

For the status half, pick any independently-hosted status tool — the only requirement is that it fails separately from you.

Start a changelog — free   Next: API changelogs →

Related guides

• Incident postmortems vs changelog: what to publish after things break
  The status page says “we noticed,” the changelog says “we fixed it,” and the postmortem says “here is what actually happened and what changes.” When an incident earns a public postmortem, the anatomy of one worth reading, and the follow-through loop almost nobody closes — tracking the promised fixes back through the changelog.
• Scheduled maintenance announcements: warning users about planned downtime
  Planned downtime is the one change you announce before it ships — and the announcement does most of the work. Which maintenance deserves a notice, the three-message rhythm, the window-writing rules, what API consumers need, and a template.
• Public roadmap vs changelog: which one do you actually need?
  Promises vs proof: when a public roadmap is worth its upkeep, when a changelog alone is stronger, and how the two feed each other.

Last updated 2026-07-26 · All guides