Announce scheduled maintenance, report incidents. Before anyone calls.
Your status page shows what your checks see, and you add what only you know: incidents with updates in phases, scheduled maintenance with reminders and an honest postmortem afterwards. One outage becomes one message instead of a hundred tickets.
Made and Hosted in the
European Union
GDPR-Compliant Hosting
in Germany
GEO-Redundant Replica
across the EU
The status comes from your checks.
Every row on the status page is a component: a monitor, a third-party service or an entry you maintain yourself. Monitors set their own status as soon as an outage is confirmed and show their availability as bars, 30 days by default and up to 90. You sort components into groups and change a status by hand with one click when needed.
- Automatic status from the monitor, so the page shows an outage without anyone having to remember at night.
- Third-party providers as their own component: embed the status of services such as Cloudflare or bunny.net, so your client sees when the problem is not on your side.
- Groups by drag and drop, so pages with many services stay easy to read.
`sourceKind` is `monitor`, `dependency` or `manual`, with up to 100 components and 100 groups per page. Monitors derive their status from open incidents: `operational`, `maintenance`, `degraded` (certificate notice only), `partial_outage` (the site answers, another check fails) or `major_outage` (down). Manual components take one of these values through `manualStatus`, and a linked open incident can raise it.
Third-party providers come from our public dependency monitoring. Their status `unknown` shows as a notice but does not count toward the overall status. `overallStatus` is the most severe status of all components, and `major_outage` only applies when everything is down. Raw check data never leaves the platform.
One incident, four phases, no guesswork.
When things are on fire, nobody wants to write from scratch. You report the incident with title, affected components, status and severity, pick a template if you like, and follow up with updates: investigating, identified, monitoring, resolved. Every update appears on the page at once and goes out to subscribers.
- One form per incident, with no collapsed sections, so the first message is out within a minute.
- Templates for incidents and updates, so tone and content are right even at 3 a.m.
- A postmortem below the incident, so your client can read afterwards what happened and what changes.
A manual incident has a title of up to 200 characters, a summary of up to 5,000 characters and a severity of `minor`, `major`, `critical` or `maintenance`. That sets how it shows: `degraded`, `partial_outage`, `major_outage` or `maintenance`, overridable through `impact`. It appears on up to 10 pages and up to 100 components. Updates carry the phase `investigating`, `identified`, `monitoring` or `resolved`. An identical repeated update is recognized and not sent twice. A new update on a resolved incident reopens it.
Templates come as `incident` and `update`, up to 200 per organization, with text of up to 5,000 characters and preselected pages and components. The postmortem is Markdown of up to 50,000 characters and only notifies subscribers if you explicitly choose that when publishing. Over MCP: `create_incident`, `post_incident_update`, `publish_postmortem`.
Maintenance announced. No outage in your client's eyes.
An update on Sunday evening is not an incident if your client knows about it in advance. You schedule the maintenance with a time window, affected components and a text. It starts and ends on its own, the components show maintenance during that time, and your subscribers get the announcement, a reminder and the completion.
- Automatic start and end, so nobody has to flip the status at midnight.
- A reminder between 5 minutes and 7 days ahead, so your client can warn their own people in time.
- For the whole page or single components, so database maintenance does not show the entire shop as disrupted.
The state is never stored but computed: `scheduled` before `scheduledFor`, `in_progress` until `scheduledUntil`, then `completed`, and `cancelled` once `cancelledAt` is set. A worse state such as an outage takes precedence. Title up to 200, description up to 5,000 characters, 1 to 10 pages, up to 100 components from any source.
`notifyOnSchedule` (on by default) announces and announces again if the start moves. `reminderMinutesBefore` 5 to 10,080, `notifyOnStart` (off by default), `notifyOnComplete` (on by default). Whether a message is sent is decided at send time, so a moved or cancelled maintenance never sends an outdated message. Every event also appears in the RSS and Atom feed. Important: this maintenance does not pause monitor alerts. Use a maintenance window in monitoring for that.
A history that adds up. Retroactively too.
Not every outage runs through your checks. An incident that is already over can be backfilled with a fixed start, a fixed end and updates at their own times. It shows in the history and the uptime bars without sending subscribers a late notification. Rules decide whether monitors and incident management write to the page.
- Backfill an incident with its own timestamps, so the history is complete even when an outage was noticed outside monitoring.
- Browse the history by quarter, so your client can follow older incidents too.
- Rules per page, so you decide whether monitors and incident management set the status automatically.
A backfill needs `started_at` and `resolved_at` in the past and up to 50 updates with their own timestamps in between. It appears in the history and in the uptime bars of the affected manual components and never notifies subscribers. Over MCP: `backfill_incident`.
`historyPage` 1 covers the current and the two previous calendar months, each further page the three months before, with up to 200 incidents per page. The uptime bars show the last 30 days by default, adjustable up to 90. Incidents from incident management only appear with at least one public update. The public page never returns team, responders or internal notes, and authors show as first name and initial.
We don't just monitor. We help you sell.
Every Uptimeify subscription includes access to our Success Kit, a collection of battle-tested resources to turn your monitoring into a profit center.
Service Level Agreement templates to define professional boundaries with your clients.
Find the sweet spot for your care plans. Calculate margins based on check frequency and support hours.
Powerpoint Templates that explain 24/7 monitoring to non-technical clients. Close more retainers.
Use automated reports to proactively communicate value, so clients never ask what they're paying for.
Ready to turn monitoring into a profit center?
Claim your Success Kit and start scaling today.
Frequently Asked Questions
You schedule a maintenance with a title, time window, affected components and a short description. On save, the announcement goes to your subscribers, and a reminder, a start notice and a completion message can follow. During the maintenance, the components show maintenance instead of an outage.
No. Maintenance on the status page is communication with your clients. To keep your team from being paged during that time, add a maintenance window in monitoring as well. That keeps both decisions deliberately separate: what the client sees and who gets woken up.
No. Components linked to a monitor change their status automatically as soon as an outage is confirmed across several locations, and return after recovery. You report an incident by hand when you want to say more than the status, such as the cause or your next estimate.
A public review of a resolved incident: what happened, why, and what you are changing. It appears directly below the incident. Whether your subscribers get a message about it is your choice when you publish. An open postmortem shows your client that you take outages seriously.
The uptime bars show the last 30 days by default, adjustable up to 90. Beyond that, the incident history can be browsed back quarter by quarter, as long as the incidents are stored. Incidents that did not run through your monitoring can be backfilled, so the history stays complete.
For the technical stakeholder
Ready to explain outages before anyone asks?
Link your monitors, set up two templates and schedule your next maintenance. Next time something breaks, you write one update instead of a hundred replies.