- The first line shows when the page was last checked, with the time zone.
- Each service appears once, with one status word from the fixed list.
- Every active incident has a start time, a current status and the affected services.
- Any statement that something works is limited to what was actually checked.
- The next update has a time, or a plain reason why no time is given yet.
- Resolved incidents say what changed and when, and do not name a root cause that is not confirmed.
- The page has been regenerated with the current status, and its date shows that.
- No internal server names, staff names or customer details appear.
Technical & ProductContent Creator
Status page: a dated summary of what is affected and when the next update comes
A status page is a public summary of whether a service is working, what is affected, and when the next update will come. A static page is accurate only as of its last update, so the timestamp and the next-update time matter more than any single status word. Use plain status words, date every change, and do not say a problem is fixed until someone on your team has checked it.
Weak and strong wording
Rewrite vague status lines into lines readers can check
Weak: All systems are operational.
Strong: Checked 9:40 a.m. Central: online orders, checkout and account sign-in are working.
A green line is a claim about a time and a set of services. Name what was checked and when, so readers do not take it as live.
Weak: Some users may be experiencing issues.
Strong: Since 8:15 a.m. Central, some customers cannot see saved addresses at checkout. Orders are still going through, and we are looking into the cause.
Says who is affected, what still works and what the team knows. Vague wording sends people to support to find out whether they are affected.
Weak: This issue has been resolved.
Strong: Saved addresses appeared again at checkout as of 11:20 a.m. Central. We will post a follow-up by 3 p.m. Central to confirm that nothing else is affected.
States what changed and when, and promises the next update so readers know whether to wait.
Weak: We will update soon.
Strong: Next update: 2 p.m. Central, or sooner if the status changes.
A time gives readers something to check. Promise only a time you can keep, and if you cannot, say when you will post the reason for the delay.
Example excerpt
Sample status page: a library catalog with a delayed-email incident
Sample section
Illustrative example: the library, its services and its times are fictional. Service status Last checked: Tuesday, October 13, 2026, 9:40 a.m. Central. Next update: 1:00 p.m. Central, or sooner if anything changes. Current status Catalog search: Operational Account renewals: Degraded. Renewals work, but confirmation emails can take up to an hour to arrive. Room bookings: Maintenance. Bookings are paused from 6:00 to 8:00 p.m. Central on Thursday for a system update. Incident: Delayed renewal emails Started 8:20 a.m. Central. Cause: a backlog in the email queue after a server restart. Renewals are recorded when they are submitted, so please do not submit a renewal a second time. 10:05 a.m. Central: The backlog is cleared and new emails are arriving normally. The team is watching the queue for one more hour before it closes this incident. Need help? Call the front desk during opening hours, or send a message through the contact form. Do not include your password in any message.
Section outline
Sections in the order readers scan them
Title and last-checked time
The service name, the date and time the page was last checked, and the time zone. Put these above everything else.
50 wordsComponent status
Each part of the service with one status word from a fixed list and one sentence on what it means for the reader. Use the same five words every time: Operational, Degraded, Partial outage, Major outage, Maintenance.
120 wordsActive incidents
What is affected, what still works, when it started and the current action. Newest update first, with every time in the same zone.
200 wordsRecently resolved incidents
Each closed incident with its start and end times and what changed. Name a cause only once it is confirmed.
120 wordsPlanned maintenance
Dates, times and the services affected by work you have scheduled, with the time the work should end.
80 wordsHow to get help
The contact route for affected readers and the details to include, such as the time of the failed action.
60 words
Total: 630 words
Quality checklist
Check the page before each update goes out
Mistakes to avoid
Ways a status page loses reader trust
Leaving the page at green
A page that still says operational after the problem has started is worse than no page. Update the status as soon as the team knows about the problem, even if the update says only that it is being investigated.
Writing for engineers
A line such as upstream timeout tells a customer nothing about what they can do. Describe the effect first, and add the cause only after it is confirmed.
Leaving out the time zone
A time without a zone makes readers in other regions guess. Choose one zone, state it on the page, and use it on every line.
Going quiet after a promised update
If you said the next update would come at 2 p.m., post at 2 p.m., even when the message is that nothing has changed. A missed promise sends people to support.
Treating a hand-updated page as live monitoring
A page that someone regenerates shows the last time it was updated, not what is happening now. Show the last-checked time near the top. If readers need automatic detection and alerts, use a hosted status service that monitors your systems.
Share the finished page
Put the link where readers will look for it
Public link
Share the public link where people already look for news about the service, such as the help menu, order confirmation emails or the sign-in screen. Every reader should see the same last-checked time.
Team link
Give staff who are workspace members the team link, so that anyone answering a message uses the same wording as the page. Ask them to check it before they quote a status to a customer.
WhatsApp share button
Send the link to a customer group you already message, with the last-checked time in the message. Post again when the status changes, not on a timer.
HTML download
Download the HTML file to keep a dated copy of each version. Name the file with the date and time it reflects, so the record of what readers saw is clear.
Frequently asked questions
Can a status page update itself?
No. The page is a snapshot. It does not check your systems, pull live data or change when a service fails. Someone on your team updates it by generating a new version with the latest status, then shares the updated link or file.
Is a status page the same as uptime monitoring?
No. Uptime monitoring checks a service on a schedule and sends alerts when a check fails. A static status page shows only what your team last wrote. If readers need automatic detection and posted updates, a hosted status service built for that job is the better fit.
Do I need a status page template?
A layout helps, but the wording matters more. Start from the fixed status words, the last-checked line and the incident update format in this guide, and write the specific text for your service. Avoid any default line that says everything is operational, because it will stay on the page after a problem starts.
How often should I post updates during a problem?
Post when the status changes and at each time you promised. Choose an interval you can keep, state it on the page, and keep to it. A missed promise costs more trust than a slower schedule you meet.
Browse by category
More pages in Technical & Product
Pages
Interactive Prototype
Documents
Technical Specification
Reports
Wait-time Dashboard
References
Tutorial Page
References
Code Snippet Library
References
API Documentation
How to build it
Follow the eight-step wizard: type, assets and description, images, branding, contact and call to action, Atty Suggestions, blueprint, and generate. Atty generates one HTML page in the background. Review it, then publish and share the page link or download the HTML file.
