Works with your incident management. Closes the notification gap, with proof.
Ackline does not replace the incident management tool you run. It sits alongside it and covers what regulated teams still have to show: that the right person was notified, at the right loudness, and that the delivery, the routing decision and the acknowledgement were recorded.
Join the waitlist See integrations
Status: in development. There is no public release, no pilot programme and no customer list to show. This site describes what we are building, what exists today and what is only planned.
The gap
Incident management and on-call tools run the process. After an incident, someone still has to answer: which alert fired, who was told, how loudly, and when did a named person acknowledge it? In a regulated firm that question comes from an auditor, a supervisor or an incident review, and the answer is often reassembled from chat logs and screenshots.
Ackline closes that gap. Alerts come in from the monitoring tools you already use, reach the person on call, and leave a record you can hand over.
If you own operational resilience
You need evidence, not assurances. For each alert, Ackline records the source, the routing decision with its inputs, each delivery attempt and the acknowledgement. Nothing is deleted. Your incident process stays where it is.
If you are on call
One inbox on your iPhone. Your schedule and calendar set whether an alert interrupts you or waits quietly. Critical alerts ask for Face ID or a passcode to acknowledge; normal ones need a tap.
How routing works
Routing decides one thing: how loud an alert should be for the person receiving it. It never decides whether the alert exists.
- Always delivered. The routing output is a notification level, interrupting or quiet. It is never "deliver" or "suppress". Off-call alerts still land in the inbox, without waking anyone.
- Schedule aware. The on-call schedule and the person's calendar set the level. With no schedule, the person is always on call.
- Reproducible. Routing is a plain function of the user, the schedule, the event and the time. Given the stored inputs, the same decision comes out again.
- Deterministic. No model decides who gets woken. We do not use AI for routing decisions.
How the audit trail works
Each step in an alert's life is a separate entry, with its inputs and a UTC timestamp. Evidence levels are kept distinct, so the trail does not claim more than is known: Apple accepting a push for delivery is recorded as sent, not as delivered or seen.
- Acknowledgement is final and cannot be undone.
- Alerts are archived, never deleted.
- Audit entries are intended to be cryptographically protected against change. We will describe exactly what is protected, and how, once it has shipped.
Worked example (synthetic data)
This is an invented alert, shown to illustrate the shape of the trail. It is not from a real system or customer.
2026-01-15T02:14:09Z event.received source=webhook severity=critical
2026-01-15T02:14:09Z routing.decided user=on-call-1 level=interrupting
inputs=schedule:night-rota, rule:critical-always-interrupts
2026-01-15T02:14:10Z push.sent user=on-call-1 accepted-by-apns
2026-01-15T02:16:41Z alert.acknowledged user=on-call-1 method=face-id
What works with what
Alert sources come first, then schedule importers, then calendars, then two-way sync with ServiceNow and Jira Service Management. Each integration is labelled available, in progress or planned on the integrations page, and the roadmap shows the tentative order. Tell us which tools you use on the waitlist: your answer steers that order.