MTTA, MTTR and an audit log for your team. Every incident becomes a lesson.
See how fast your team responds and resolves, write postmortems with real action items and keep every change in the audit log. If NIS2 applies to you, document report cases and deadlines in the same place.
Made and Hosted in the
European Union
GDPR-Compliant Hosting
in Germany
GEO-Redundant Replica
across the EU
Numbers instead of gut feeling.
How long does it take your team from the first alert to an acknowledgement, and how long to a resolution? The incident report shows it per team, severity, category, service or month. The on-call report shows who carried how many hours. Both back your response promise to clients with real figures.
- MTTA and MTTR per team and severity, so you see where response stalls instead of guessing.
- On-call minutes per person as CSV, so on-call duty is shared fairly and paid correctly.
- Noise per day: incoming alerts, grouped duplicates and the incidents they became, so you see whether your team works on signal or on noise.
GET /api/im/analytics returns volume, MTTA and MTTR per local day, daily alert load and on-call minutes per person in one call, for up to 400 days. MTTA and MTTR only average incidents that were actually acknowledged or resolved, open ones do not count as zero. Test incidents are excluded.
GET /api/im/reports/incidents groups by month, team, severity, category or service and returns JSON or CSV with the columns <groupBy>,count,mttaMinutes,mttrMinutes. The on-call report comes as userId,userName,minutes,hours. Incidents are kept in full for twelve months, after which a daily aggregate carries the metrics up to 24 months.
Resolved is not the end.
The outage is fixed, but why did it happen, and what will you change? The postmortem captures summary, impact and root cause, picks the cause from a shared catalog and assigns action items with an owner and a due date. The follow-up view shows what is still open.
- Postmortems with a cause catalog, so the same cause always has the same name and patterns become visible.
- Action items with owner and date, so "we should really fix that" becomes a task someone closes.
- Follow-up at a glance: incidents without a postmortem, open and overdue actions and repeated causes, so nothing fades after the incident.
A postmortem belongs to exactly one resolved incident: summary, impact, rootCause, causeId and lessonsLearned, up to 10,000 characters each. Completing it requires summary, root cause and a catalog entry, after which the content is locked. Causes are never deleted, only archived. Action items carry ownerUserId, dueOn and the status open, done or dropped.
With NIS2 mode on, a postmortem is due from postmortemMinSeverity (default sev2), for the security category or with a linked report case. A cause found in at least two completed postmortems within six months counts as repeated. Uptimeify only counts, and the judgement stays with you. A quarterly review freezes the figures and is kept for three years.
Who changed the escalation? It's in the log.
When an alert reached nobody at night, you want to know why. The incident management audit log records every change to teams, members, schedules, overrides, escalation tiers, sources, routing, channels and settings: who, when and exactly what applied before and after.
- Every change with before and after, so you find a wrong setting in minutes rather than hours.
- Filters by area, person and time range, so a question from a client meeting gets a documented answer fast.
- Organization log as CSV, sign-ins and sessions included, so you can hand auditors and clients a clean export.
GET /api/im/audit-log returns entries newest first, each with action (create, update, delete), a diff in the form {field:{from,to}} and the actor. Secrets never enter the log, and rotations show as "rotated" or "set". Filter by entityType, actor and time range, paginated by cursor with up to 200 entries per page. Access is limited to organization admins.
The organization log export (GET /api/organization/audit/export) delivers administrative actions and sign-in events as a CSV with eleven columns, up to 366 days and 100,000 entries per export. Entries are kept for twelve months and cannot be changed or deleted in the application. Every export is itself logged.
NIS2 deadlines in view. You do the reporting.
If your organization falls under NIS2, every hour counts after a significant incident. A report case groups the affected incidents, walks you through the criteria for the decision, shows the deadlines from the moment of awareness and prepares report drafts. You submit in the BSI portal yourself, and Uptimeify documents what you submitted and when.
- Deadlines from awareness: early warning within 24 hours, notification within 72 hours, final report one month after the notification, so no deadline gets lost in daily work.
- Report drafts in German or English, so you never start from a blank form under time pressure.
- Submission log and management report: what you submitted is kept with the BSI reference, and the quarterly PDF supports management oversight.
A report case moves through assessment, not_reportable or reportable, then early_warning_submitted, notification_submitted, final_submitted and closed. It links up to 50 incidents. Ten criteria are confirmed or rejected by a person, and suggestions from monitoring data exist only for a total outage over 30 minutes and for planned maintenance. The decision is possible once every criterion is decided, and "not reportable" requires a reason.
Drafts exist for early warning, notification, interim, progress and final report. When you log a submission, the server freezes the submitted text with its reference as evidence, and stages follow the legal order. Uptimeify transmits nothing and never classifies an incident on its own. Closed report cases are kept for three years.
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
MTTA (mean time to acknowledge) is the average time from an incident being triggered to a person acknowledging it. MTTR (mean time to resolve) is the average time to resolution. Uptimeify calculates both per day, team and severity and only averages incidents that were actually acknowledged or resolved, so open cases do not distort the figure.
Yes. The on-call report returns minutes and hours per person for any date range, as JSON or CSV. Shifts are cut cleanly at the edges of the range, and overrides are included. That gives you a solid basis for on-call allowances and a fair split across the team.
Whenever an incident noticeably affected clients or could happen again. With NIS2 mode on, Uptimeify makes it explicit: a postmortem is due from a configurable severity, sev2 by default, as well as for security incidents and linked report cases. The follow-up view shows which incidents still lack one.
No. You submit every report yourself in the BSI portal. Uptimeify transmits nothing and never classifies an incident on its own. It supports you with criteria, deadlines from the moment of awareness, report drafts and a log that records which text you submitted, when and under which reference.
Incidents with their timeline are kept in full for twelve months, and daily metrics for up to 24 months. Postmortems, closed report cases and quarterly reviews are kept for three years, the organization audit log for twelve months. Raw payloads of incoming alerts are cleared after 90 days.
For the technical stakeholder
Ready to learn from every incident?
Switch on analytics for your team, write your first postmortem and set up your causes. Your team sees where it gets faster. Your clients see that you can prove it.