From system failure to bedside alarm in two seconds.
Crit Alarm turns standard HTTP requests from your servers into loud, persistent sirens on your phone. Post, ring, acknowledge, close.
The alert pipeline
Your systems post. The server opens an incident. The relay wakes the phone. The phone rings.
Your systems
Uptime Kuma, cron, shell scripts, or CI pipelines post standard HTTP webhooks to your topic URL.
Server engine
The server validates the bearer token, opens an incident row in SQLite, and starts durable timers.
Wake-up ping
The relay pokes Apple APNs and Google FCM with an opaque hash. Your alert text does not go through it.
Critical alarm
Your phone gets the ping, fetches the incident from your server, and sounds the alarm.
Create a topic and configure delivery
Every topic gets a dedicated endpoint and a private bearer token. There are no public topics.
Topic security and privacy
You name your topic, for example prod-db or nas-backup.
The server assigns a secret token prefixed with ca_live_.
Only callers holding this token can publish alerts or query incident status.
Critical delivery starts OFF on every new topic. You turn it on in the app for the topics that need to wake you.
Generated topic endpoints
Publish from any server, script, or webhook
Crit Alarm speaks ntfy-compatible HTTP. Anything that can make an HTTP request can alert you.
Simple curl publish
curl -X POST https://api.critalarm.app/t/prod-db \
-H "Authorization: Bearer ca_live_7Hq2mN9xPz4wKd8" \
-H "Priority: critical" \
-H "Title: Primary database down" \
-H "Tags: postgres,db-1" \
-d "pg_isready failed 3 times in 90 s. Replica promoted to primary on db-2."Uptime Kuma configuration
# In Uptime Kuma:
# Notification Type: ntfy
# Server URL: https://api.critalarm.app
# Topic: prod-db
# Priority: 5 (Critical)
# Authentication: Bearer ca_live_7Hq2mN9xPz4wKd8Supported HTTP headers
-
Authorization: Bearer <token>Proves the request is allowed to publish to your topic.
-
Priority: criticalSelects severity (min, low, default, high, critical, or numbers 1 to 5).
-
Title: <summary>The headline on the lock screen.
-
Tags: postgres,db-1Labels you can filter by in the app.
-
Actions: view, Dashboard, https://...Buttons on the notification.
What the relay sees
The relay never sees your hostnames, your logs, or the text of your alerts.
What goes through the relay
When an incident opens, your server sends Apple and Google a hash of the topic name and the incident id. Nothing else.
Your phone then asks your own server for the title, the body and the priority. Apple and Google never see any of it.
What each side sees
{"topic_hash":"a4f9b2...","incident_id":"inc_01J7Q"} "pg_isready failed 3 times in 90 s. Replica promoted."
The 3am bedside critical alarm
When a priority 5 alert arrives, the phone sounds an alarm and keeps sounding it.
What the alarm does
On Android the alarm takes over the whole screen and plays at alarm volume. On iOS it arrives as a Time-Sensitive notification.
- Plays at alarm volume
- Repeats every 30 seconds for up to 60 minutes
- Escalates to a second device after 5 minutes
- Stops when you acknowledge
Two-stage resolution: wake up, then close
Acknowledge the siren from your bedside. Close the incident once you reach your computer.
"I am up" (Acknowledge)
You tap Acknowledge from your lock screen, notification action, or watch. The siren stops immediately. The screen flips to cobalt.
A desk timer starts (default: 10 minutes). If you fall back asleep and it runs out, the alarm starts again.
"At my desk" (Close incident)
Once you reach your workstation and resolve the root cause, you close the incident. Close it from the app or with an API call.
# Acknowledge an incident from your workstation terminal
curl -X POST https://api.critalarm.app/t/prod-db/ack \
-H "Authorization: Bearer ca_live_7Hq2mN9xPz4wKd8" \
-d '{"incident_id":"inc_01J7Q"}'One incident, start to finish
A failover at 03:12, acknowledged at 03:14.
- Delivered
- 03:12:04
- Rang
- 4 times, 30 s apart
- Acknowledged
- 03:14:18 by Z
- Escalation
- not needed
If the server restarts
A reboot in the middle of an incident does not stop the alarm.
When the server comes back it picks the incident up where it left off and keeps ringing.
Your control over the alarm
Critical defaults to OFF
Every new topic starts non-critical. You choose which ones may wake you.
Every topic has a token
Publishing needs the topic token. Nobody else can push to your phone.
The app never invents an alert
The app never generates alerts on its own and never inspects device contents.
You can turn it off
Turn critical delivery off for one topic, or for everything, in Settings.
Ready to wire up your first topic?
5 free topics on our server. Unlimited on yours.