In short
Keep the status page separate from the service it reports on.
Show each component, the current incident, what still works, and the next update time.
Keep resolved incidents visible so readers can distinguish a current outage from the history.
Open the reader link on a phone and test one real update before you rely on it.
We built a fictional status page for the Northstar developer service in one HTML file. The page begins with a partial outage, lists three service components, records two incident updates, and keeps two earlier events in a history. We then saved it in NOS, opened its reader link, changed the headline to “Monitoring recovery,” and checked the same reader link again.
Download the complete fictional status page
What should an API status page show?
Start with the answer a reader needs: is the service usable, and which part is affected? A single green or red label is too coarse when authentication works but uploads do not. The example separates authentication, data reads, and file uploads, then gives each one its own state.
The incident card adds the details that a component badge cannot carry. It names the affected action, says that uploads are accepted but delayed, states that authentication and reads remain available, and gives the next update time. Every sentence narrows what the reader needs to check.
Build the page in reader order
- Overall state. Put the current service condition at the top.
- Components. List the parts a reader can recognize, not internal team names.
- Active incident. State what is affected, what is not affected, and what is being checked.
- Next update. Give a specific time and use one time zone throughout the incident.
- History. Leave resolved events below the active incident.
That order keeps the urgent answer above the supporting record. A reader can stop after the component list or continue into the incident timeline when they need more detail.
Host the status page away from the service
A status page cannot explain an outage if it depends on the same failed service. Put the page on a different hosting path and avoid loading its essential text from the service it reports on. The example is self-contained: its status text and styling are in one file, so the page does not need the fictional Northstar service to render.
This does not make the page immune to every failure. It removes one direct shared dependency. Keep the reader address somewhere responders can reach even when the product dashboard is unavailable.
How do you share the status page?
Save the page, open Share, and copy the reader address. The Share panel we used says that anyone with the link can read the page without signing in and cannot edit it. That is the address to place in support replies, incident messages, or a product footer.
Open that reader address before distributing it. The first phone-width check showed the fictional label, the service name, the partial outage, and all three component states without an account prompt.
How do you update a status page during an incident?
Use a short sequence that one responder can repeat:
- Confirm the observed condition and affected components.
- Write the new incident state in plain language.
- Keep the previous update in the timeline instead of replacing the record.
- Set the next update time, even when the investigation is still open.
- Save, then reopen the reader address and compare the visible result with the intended update.
We tested the save-and-check part on the existing page. Edit mode opened with the status summary visible. We selected the current headline through the normal browser editing flow, changed “Partial outage” to “Monitoring recovery,” and chose Done.
The reader address did not change. Reopening it showed the revised headline, which verifies the result a recipient would see. We did not change the component badge from Degraded because the fictional evidence only supported a recovery-monitoring headline, not full resolution.
What failed in the test, and how should you handle it?
The public page is rendered in an isolated frame, so the outer page cannot reliably read the status text as ordinary document text. That is not proof that the page failed. We checked the visible screenshot instead and confirmed the headline, component list, and incident card.
Empty or broken page? First open the saved page in View. If View is empty, return to Code and check that the file contains a complete HTML document. If View works but the reader address does not, create or reopen the Share link and test that exact address in a separate browser view. Keep the old incident text until the new visible result has been checked.
Keep the useful parts of the original status-page plan
The original guide was right to prioritize separate hosting, an early update, the unaffected area, a promised next-update time, and visible incident history. The worked page makes those rules concrete. It also adds the missing component list and the complete path from a one-file example to a checked reader link.
For the operating record behind the public page, use an incident management procedure to assign response roles and recovery checks. Track unresolved work in an issue log. After a product change ships, move customer-facing changes into release notes instead of leaving them in incident history.
When not to do this
Do not treat a static status page as monitoring, paging, or an incident-management system. It does not detect failures or prove recovery by itself. For many services, regions, subscriber notifications, or automated uptime data, use a dedicated status platform and keep a manual publication path for cases where automation reports the wrong condition.
Where NOS fits
NOS can hold the self-contained HTML page, let its owner review it in Code, View, and Edit, and provide a reader link. In this example, the reader link opened without a sign-in prompt and reflected a saved text change. The HTML file and screenshots here are local preparation assets; this rewritten article and its assets have not been added to the live learn page.