Stasys

The status page runs on its own server so that it is still there on your worst day. Stasys will not install it on its own server. Keep it off the systems it reports on too.

What it shows

• Components - the services you report a status for, in groups.
• Incidents - written for customers, and separate from your internal ones. What you tell the world is your decision, not a copy of your alerts.
• Updates - the timeline on each incident.
• Maintenance - planned windows, announced in advance. If you use the AI staff, maintenance and update notices can post themselves, from a fixed template that never shows an address, a server name, a path or a secret, and at most one public notice a day.
• Subscribers - people who would rather be told than check. Anyone can sign up by email and confirm; you can also add Slack, Discord, Microsoft Teams or webhook targets. Subscribers are told about incidents and planned maintenance.

Outside checks

The status server checks your public services itself, and from any extra check locations you add in other regions (Status page → Probe nodes). Each component shows the response time from each location.

When three or more public checks fail and enough of your locations agree, the status page opens a public incident on its own, tells subscribers and pages your on-call. It closes it again once the checks pass.

Honest status

When an incident is resolved in Stasys, the public page shows it as monitoring for 30 minutes by default, and marks it resolved only if the problem stays away. If it comes back, the page says so.

For your own tools

• /api/v1/summary - the current status as JSON.
• /feed.xml - incident updates as a news feed (Atom); /rss leads there too.