Incident response from alert to resolution. No phone tree required.
Every incident reaches the team that owns it, gets acknowledged in one click and gets clear roles. Every step lands in the timeline, and your status page follows along, so your client is informed before they pick up the phone.
Made and Hosted in the
European Union
GDPR-Compliant Hosting
in Germany
GEO-Redundant Replica
across the EU
The alert reaches the right team. Not a shared inbox.
Routing rules decide which team gets a new incident: by source, severity, client, monitor, tag or any field in the alert. The first matching rule wins. If none matches, the incident stays with the source's team. Nobody has to sort in the morning what came in overnight.
- Rules in a set order, so database alerts from your largest client reach the backend team and not the frontend.
- Override severity while routing: a "warning" from a client's shop becomes a sev1, so critical systems never depend on the tool's own judgement.
- Services with criticality and an owner: every incident knows the affected service and the responsible team, so priorities do not live in individual heads.
Rules are checked by ascending priority (default 100), then by id, and the first match wins. Every condition of a rule must match: sourceIds, severity, customerIds, monitorIds (up to 500 each), tags (up to 200, case-insensitive) and fieldMatches (up to 50 keys). An empty {} matches everything. customerIds and monitorIds only apply to alerts from the monitoring bridge. severityOverride sets sev1 to sev4.
Services carry the criticality critical, high, medium or low and an optional owner team. When the monitoring bridge opens an incident and the monitor belongs to exactly one service, the service is set automatically. Otherwise you assign it by hand.
One incident, one record.
One click on acknowledge, or 4 on the phone, and the paging stops. From then on everyone on the team sees who took over, where the incident stands and what has happened so far. Investigating, identified, monitoring, resolved: every step lands in the timeline with time and person, and the timeline carries the postmortem later.
- Acknowledging stops escalation, in the app or with a key press on the phone, so nobody gets woken up needlessly after the first response.
- Clear incident roles: incident commander, tech lead, comms and assignee, so nobody duplicates work in a major outage and nobody forgets client communication.
- Merge instead of working twice: when two tools report the same outage, Uptimeify suggests merging, so your team works on one incident, not two.
Open statuses are triggered, acknowledged, investigating, identified and monitoring. Closed ones are resolved and merged. POST /api/im/incidents/:id/ack is idempotent and open to everyone with incident management access, because an acknowledgement only ever stops paging. Status changes are reserved for the incident's team. Jumping straight from triggered to investigating does not count as an acknowledgement. Only the dedicated resolve endpoint reaches resolved.
A merge moves alerts and timeline into the target incident, and the source incident stops escalating. Suggestions appear for open incidents from other sources with the same service or host within 15 minutes. Snooze pauses escalation and reminders for up to seven days, and bulk actions apply to up to 200 incidents with a result per incident.
Your team lives in Slack. The incident goes there.
Nobody should keep yet another tool open just to know what is on fire. Outbound integrations send incidents where your team already works, and filters make sure each channel only gets what belongs there.
- Slack, Microsoft Teams, Discord, Jira, PagerDuty, Opsgenie and webhooks, so chat, ticketing and existing processes all know about the same incident.
- Filters by team, severity and event, so the management channel only sees sev1 incidents and Jira gets exactly one ticket per incident.
- Delivery history with resend: every delivery is traceable for 90 days, so after an error you see what arrived and resend on purpose.
Types: slack, teams, discord, jira, pagerduty_v2, opsgenie (region eu or us, default eu) and webhook. Filters cover teams, severities and eventKinds (incident_created, acknowledged, severity_changed, status_changed, comment, resolved). Jira starts with incident_created, which means one ticket per incident.
Secrets and webhook URLs are stored encrypted and never returned, and private or local targets are rejected. The delivery history shows sent, failed or retrying. A manual retry, up to ten per minute per integration, sends the current state of the incident, not the old payload.
Your client sees the status before they call.
Your team works on the incident internally, and your client only sees what they should see. Status page rules switch the right status page to degraded as soon as an incident of a team reaches a set severity, and back again once it is resolved. The public text is yours to write.
- Rules instead of manual updates: incidents of a team from sev2 upward set the status page to warning or degraded, so your client is never the first to notice.
- Your own public text in the phases investigating, identified, monitoring and resolved, so internal notes stay internal.
- Back to green automatically once the incident is resolved, so the status page never shows an outage that ended days ago.
A rule reads: incidents of team X from minSeverity (default sev2) set status page Y to targetState (warning or degraded, default degraded), optionally for selected components only. autoResolve (on by default) resets the state on resolution. A manual override pins operational, warning or degraded with a message of up to 5,000 characters, and rules cannot overwrite it.
The public text of an incident has the phases investigating, identified, monitoring and resolved, and the public timeline is append-only. Subscribers are only notified when the text changes. Only admin and editor can set public texts.
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
An alert is a single signal from one source, for example a message from Zabbix. An incident groups all alerts that belong to the same problem and is what your team works on. Paging, acknowledging and resolving happen on the incident. An outage reported by five tools creates one case, not five.
A new incident starts as "triggered". Acknowledging makes it "acknowledged", and the team can then move it to "investigating", "identified" and "monitoring". It closes as "resolved" or, if it was folded into another incident, as "merged". Every change is in the timeline with time and person.
Anyone with access to incident management, meaning the admin, editor and responder roles. You acknowledge in the app, through the link in SMS, email or push, or with 4 during an alert call. Acknowledging only stops paging, which is why it is deliberately open. Changing an incident's status, on the other hand, is limited to members of its team and organization admins.
Yes. Outbound integrations send events to Slack, Microsoft Teams, Discord, Jira, PagerDuty, Opsgenie or your own webhook. Each integration filters by team, severity and event type. Jira creates one ticket per incident by default, and every delivery stays traceable in the history for 90 days.
No. Incident management is an internal tool for your team, and client logins have no access to it. What your client sees is controlled through your status page: the state set by your rules and the public text you approve. Internal roles, root-cause comments and on-call schedules stay with you.
For the technical stakeholder
Ready to close every incident cleanly?
Set up your first routing rules, connect Slack or Teams and link your status page. On every incident your team knows who owns it and what comes next. So does your client.