The lifecycle
From signal to proof.
Every critical alert follows one stateful flow — not a fragile chain of automations. Here is exactly what happens between a sensor firing and an auditor signing off.
- 02:00:00Freezer #3 — temperature excursion (+2.1 °C over limit)CRITICAL
- 02:00:01Push to the my-iris app → on-call: AnnaPUSH
- 02:05:01No answer → voice call to AnnaVOICE
- 02:06:01No answer → push to the next person: MikkoNEXT
- 02:06:40Acknowledged in the my-iris app by MikkoACK
- 02:06:41Resolved · end report and audit trail savedRESOLVED
- 01Signal
A signal arrives
Any sensor, monitoring system or script posts an alert to one REST endpoint — or, if it can only send an email, to a secret address instead. A freezer drifts +2.1 °C over limit, a line vibrates toward failure, a substation faults at 3 AM — my-iris treats every critical signal the same way.
- One idempotent POST /api/v1/alerts call, or a secret per-group email address
- Severity, group and per-language message in the payload
- No SDK lock-in — works from any device or platform
- 02Notify
A push to the my-iris app, then a phone call
my-iris takes the first person on the on-call list and sends a push notification to their my-iris app. The push carries no alert text: the app fetches it from my-iris over an authenticated connection. If the push goes unanswered within the window you set (5 minutes by default), my-iris calls the same person.
- The my-iris app on Android (Chrome) and iPhone (iOS 16.4 or later, added to the home screen)
- A voice call in the receiver group’s language (7 supported) when a push goes unanswered
- Every push and call recorded with its time and result
- 03Escalate
One person at a time, until someone acknowledges
No answer to the push or the call? my-iris moves to the next person on the list. After the last person it starts again from the top, leaving out anyone who skipped, until someone acknowledges or the attempt limit is reached. The state machine remembers exactly who was tried, when, and how.
- Configurable push and call windows
- Up to 20 attempts per alert by default
- Survives restarts — the alert state is durable, not in-memory
- 04Acknowledge
A person acknowledges
The recipient taps Acknowledge in the app, or presses 1 on the call. my-iris stops the escalation and records who acted and when. Skip (2) passes the alert to the next person. Everyone the alert has reached can post messages on it in the app, so the team can agree who goes on site.
- Acknowledge (1) or skip (2), in the app or on the call
- A message thread in every alert, among the people it reached
- 05Prove
An end report and an audit trail
When the alert ends, my-iris saves an end report — the alert, the outcome, who acknowledged and when, and who was notified — in the app and the console, and keeps an audit-ready record of every push, call and answer, with configurable retention. Exportable for GxP, HACCP and ISO audits.
- Tamper-evident event log: reached, acknowledged, proven
- Configurable retention; GDPR Art. 15 export & Art. 17 erasure
- EU data residency by architecture on Cloudflare’s edge
- STOP/START opt-out handled in 7 languages
- Optional SMS end report to the numbers you choose (a paid option)
Why stateful
Not a Make/Zapier chain
A no-code chain fires a step and forgets it. There is no memory of who was tried, no timer that survives a restart, no way to resume an escalation mid-flight — and no record an auditor will accept. We know: AMS v1 ran on 26 Make.com scenarios before we rebuilt it.
my-iris models each alert as a durable state machine on Cloudflare Durable Objects. The alert is the state — it remembers, waits, escalates, and proves resolution, even across deploys and failures.
- Durable timers survive restarts
- Resumes escalation mid-flight
- Remembers every attempt & reply
- Audit-ready event log, by default
- EU data residency by architecture
- One endpoint, no brittle chain
See it run on your alerts
Tell us what you monitor and who is on call. We set up your workspace with you and get your team on the my-iris app.