Looking at status pages that already work is a quick way to plan your own. The pages below are grouped by type of product. Each section notes what the page does well and how to set up the same thing in Sentivel.
Every page mentioned is public, so you can open it. None of these companies are Sentivel customers.
What good status pages have in common
- One line at the top that says whether everything is working.
- Components named the way customers think about the product, each with its own status.
- 90 days of uptime history per component.
- Incident updates in plain language, with timestamps, posted as things change.
- Email and RSS subscriptions.
- Scheduled maintenance announced in advance.
Developer tools
GitHub lists its services as separate components (Git operations, API requests, Actions, Pages) and keeps a long, searchable incident history. Cloudflare breaks status down by product and by region, which matters when a problem is local.
In Sentivel, create a component per service and attach an HTTP or TCP monitor to each. Monitors that check from several regions open an incident only when a majority of regions see the failure, so a network problem in one region doesn't show as an outage.
SaaS platforms
SaaS status pages are read by admins and end users alike. Stripe separates the API from the dashboard and gives each incident a short summary. Figma and Notion keep their pages sparse so the current state is obvious.
Group components by what customers do with your product, and write the top line for the least technical visitor. During an incident Sentivel can draft each customer update, and nothing is posted until you approve it.
Consumer apps
Consumer products get a rush of visitors the moment something breaks. Discord and Dropbox keep their pages simple and their wording friendly.
Sentivel status pages are served from an edge cache, so a page view doesn't touch a database. The page stays up during a traffic spike, and during an outage of your own backend. Keep the top line short and offer email or RSS so visitors can leave and still hear when it's fixed.
Gaming and hosting
Players care about particular servers and regions, so these pages list the control panel, the website and each game region separately.
In Sentivel, make one component per region or server, each with its own monitor, so a problem in one location shows there and nowhere else. The 90-day history per component shows players how each region has performed.
Education and collaboration tools
Classroom and team tools see most of their traffic in short windows. Their pages usually list the app, the API and real-time collaboration separately, with a short list of recent notices.
Schedule maintenance in Sentivel ahead of time, during quiet hours, so planned work shows as maintenance and not as an outage.
Agencies and small teams
A small team needs one component, an uptime history and a subscribe link. What matters more is that the page looks like the rest of your site and sits on your own domain.
Sentivel puts the page on your custom domain with automatic TLS, with your logo, colors and links. One component and no mapped providers is a complete setup.
Internal and IT status pages
Internal pages tell staff about the systems they rely on, such as portals, internal APIs and third-party services, and usually sit behind a password or login.
Sentivel supports password-protected pages. You can start private and make the page public later, and the change applies immediately.
Practices worth copying
The same few habits come up across all of these pages. Here they are, with how each works in Sentivel.
Simple design
The page exists to show the current state. Sentivel has two designs, modern and classic, both laid out so the status is the first thing you read. Add your logo and colors and leave the rest alone.
Status from real monitoring
In Sentivel each component is tied to a monitor, so its status changes when the checks change. A single failed check doesn't open an incident, and a new component shows as warming up until it has a few successful checks. That avoids the worst case: an outage in progress while the page is still green because nobody changed it.
Regular updates
Say what is wrong and what you're doing, then post again as things change. Sentivel can draft each update in plain language for you to review, which helps when everyone is busy with the fix.
Uptime history
A 90-day history lets prospects and customers judge your reliability from the record. Sentivel keeps 90 days per component, with detail for each day on hover, and you can show 30, 60 or 90 days.
Subscriptions and embeds
Sentivel offers double opt-in email updates and an RSS feed. A status badge or embedded widget in your app or docs points people to the page before they open a ticket.
Provider outages
Many outages start at a cloud host, payment provider or email service. In Sentivel you can map the providers each component depends on. When one has an incident, Sentivel marks the affected component and posts a short notice, for example: "We're aware of an issue with AWS us-east-1, a service we rely on. Some functionality may be affected until it's resolved." Nothing is linked until you link it, and the advisory is removed when the provider resolves the incident.
Publish yours
Create components that match your product, attach a monitor to each, add your domain and branding, and publish. Map providers later if you want to.