Open an incident from a confirmed outage
The same gates that decide whether to notify decide whether to open, so an incident only ever exists for a confirmed outage.
Use Uptimeify with built-in incident management.
The one integration that needs no other product. A confirmed outage becomes an incident here, with escalation, on-call and a timeline.
What happens after the alert
This is the channel that stays inside the product, so the list is about what happens after the alert. Everything the pipeline does with it is here, and nothing beyond it.
Resolve it when the check recovers
The recovery of the monitoring incident carries through to the incident here, so the timeline closes where the outage ended.
Keep the link to the monitor
Every incident carries the id of the monitoring incident it came from, so the timeline and the check history stay one story.
Cover the whole fleet
Website, heartbeat and browser checks, plus the service checks for ICMP, SMTP, SSH, TCP, FTP, IMAP and DNS, all open incidents through the same path.
Leave warnings out on purpose
A certificate or domain warning does not open an incident, because a deadline is not an outage; if it turns into one, that does.
Escalate along your policy
Once open, the incident follows your escalation tiers and the on-call schedule rather than a fixed list of recipients.
Arm it per client
The bridge is a channel like any other, so incident management can be on for the clients that pay for it and off for the rest.
Run beside the classic alerts, or instead of them
An organisation can keep the direct channels alongside, or hand the alerting over entirely, which is one setting.
Keep the timeline
Acknowledgement, escalation and resolution are recorded in order, so the question of who was told when has an answer.
Teams that run their monitoring on Uptimeify
Minutes to set up. Then it runs on its own.
1. Turn incident management on
Enable it for your organisation and decide whether it runs beside the direct channels or replaces them.
2. Set up teams and escalation
Create the teams, the on-call schedule and the escalation tiers the incidents should follow.
3. Arm it for the clients you want
Add it as a channel on the clients that should get incidents, and leave it off everywhere else.
Before you switch incident management on.
No. The same gates that decide whether a notification goes out decide whether an incident opens, so maintenance windows and flapping are already filtered when it reaches this point.
No, and that is deliberate. An expiring certificate is a deadline, not an outage. If the certificate crosses into failing and the site is down because of it, that incident does open.
Yes. An organisation can run incidents beside the direct channels or hand the alerting over entirely, which is one setting rather than a migration.
Yes. It is armed as a channel like any other, so it can be on for the clients whose package includes it and off for everyone else.
No. Your quota covers monitors and the monthly SMS and voice allowance. What an escalation sends over SMS or a voice call does count, the incident itself does not.
Every alert, and the incident it becomes, in one place.
Turn on incident management, and every confirmed outage becomes an incident with escalation and on-call, without a second product.