# Alerts that must wake someone up > A detector trips at 2 am, and a person must know within a minute. Nicolas Dao's picks for this job (Cloudless Labs, Sydney), in order of preference, what he would avoid, and what to use instead. - Use case 10 of 23 in The Stack, last reviewed 24 October 2026 - Web page: https://cloudlesslabs.com/stack/use-cases/critical-alerts/ Picks, in order of preference: 1. **[AWS IoT Core](https://cloudlesslabs.com/stack/aws-iot-core/index.md)** (Use when it fits (Proposed: research-backed, not yet confirmed by Nic)): One connection per device; alarms go to their own rule and their own queue, never behind readings. 2. **[Amazon SQS](https://cloudlesslabs.com/stack/aws-sqs/index.md)** (My default): The alarm queue: batch size 1, no batching window, its own function. 3. **[AWS Lambda](https://cloudlesslabs.com/stack/aws-lambda/index.md)** (My default): With reserved concurrency, so a backlog elsewhere in the account can't starve it. 4. **[PagerDuty](https://cloudlesslabs.com/stack/pagerduty/index.md)** (Use when it fits (Proposed: research-backed, not yet confirmed by Nic)): When the client's own on-call team is called: escalation, deduplication and the acknowledgement record built in. 5. **[Twilio](https://cloudlesslabs.com/stack/twilio/index.md)** (My default): When the people called aren't paging seats: a call that asks to press 1, with escalation in your code (an EventBridge Scheduler timer per step). Don't: - ~~Amazon SNS~~: It sends SMS, email and push, but can't call, can't tell you a person saw it, and doesn't escalate. At 2 am, none of those wakes anyone. Instead: [PagerDuty](https://cloudlesslabs.com/stack/pagerduty/index.md) or [Twilio](https://cloudlesslabs.com/stack/twilio/index.md). - ~~AWS End User Messaging~~: Its calls are one-way text-to-speech: no "press 1", no way to tell a person from voicemail, and voice is capped at 20 calls a minute. Instead: [Twilio](https://cloudlesslabs.com/stack/twilio/index.md). - ~~AWS Step Functions~~: Escalation is its textbook demo, but call, wait, call the next person is a short loop in code with a timer per step: easier to read, test and change. Instead: [Amazon EventBridge](https://cloudlesslabs.com/stack/aws-eventbridge/index.md). - ~~Amazon DynamoDB~~: A second database just for incident state. Incidents are a few rows: the paging service holds the live state, and Postgres keeps the history, written after the call. Instead: [Neon (serverless Postgres)](https://cloudlesslabs.com/stack/neon/index.md). Doesn't cover: - Certified fire alarm systems and their monitoring. A monitored fire alarm reaches the fire brigade through an approved monitoring service; this design alerts the client's people alongside it, never instead of it. - The alarm on site: sounders, and what happens locally when the internet or the power is down. Questions that change the answer: - How do the devices connect: mains power with Wi-Fi or Ethernet, batteries on 4G (LTE-M or NB-IoT), or LoRaWAN through a gateway? The network sets most of the delay, and whether alarms need a second path. - Who answers the phone: the client's own on-call team, or site managers and customers? Paging seats suit the first; calls through Twilio with escalation in code suit the second. - What delay is promised in writing, and what must still work when the internet or AWS is down? That decides whether one cloud path is enough, or a second path on site (a cellular dialler on the gateway) is needed. Worked example: [A fire alarm at 2:14 am](https://cloudlesslabs.com/stack/guides/fire-alarm/index.md) ## The picks in brief - [AWS IoT Core](https://cloudlesslabs.com/stack/aws-iot-core/index.md): Use when it fits (Proposed: research-backed, not yet confirmed by Nic). The cheapest AWS front door for device data, when the devices speak MQTT. Pricing: Sydney: $0.096 per million connection-minutes, $1.20 per million messages (metered in 5 KB steps), $0.18 per million rules triggered plus $0.18 per million actions. Basic Ingest messages carry no messaging charge. In my IoT example (5,000 devices, one message a minute), IoT Core → SQS → batched Lambda → Postgres ≈ $215–230 a month vs about $1,014–1,109 for API Gateway REST → SNS → Lambda. - [Amazon SQS](https://cloudlesslabs.com/stack/aws-sqs/index.md): My default. The queue in front of Lambda. Natural back-pressure, nearly free when batched. Pricing: Sydney: $0.40 per million requests (Standard), $0.50 (FIFO). A request carries up to 10 messages, so batching cuts the bill tenfold: 50M messages ≈ $6 batched, $60 unbatched. - [AWS Lambda](https://cloudlesslabs.com/stack/aws-lambda/index.md): My default. My default for event-driven work and heavy compute. Classic Lambda, zip-packaged, Node.js. Pricing: $0.20 per million requests + $0.0000133334/GB-s on Arm ($0.0000166667 on x86). Free tier: 1M requests and 400,000 GB-s a month, always. - [PagerDuty](https://cloudlesslabs.com/stack/pagerduty/index.md): Use when it fits (Proposed: research-backed, not yet confirmed by Nic). On-call paging for the client's own team. It calls, waits for an acknowledgement, escalates, and turns fifty events from one fire into one incident. Pricing: Professional: $21 per user a month billed annually, $25 monthly, so about $210–250 a month for 10 responders. Calls and SMS to Australia are included on paid plans. The free plan stops at 5 users and 100 calls or texts a month. - [Twilio](https://cloudlesslabs.com/stack/twilio/index.md): My default. Calls and SMS from code, including the call that has to wake someone up. Not amazing, but it works, and approval is quick. Pricing: Australia (USD): SMS $0.0515 per segment, calls to mobiles $0.075 a minute, answering-machine detection $0.0075 a call. An Australian mobile number costs about $8.25 a month (one of Twilio's pricing pages says $20: check the console). Pay as you go. An alerting month of 20 alarms and 4 drills (72 one-minute calls, 120 SMS) is about $20. ## Related - [A fire alarm at 2:14 am](https://cloudlesslabs.com/stack/guides/fire-alarm/index.md): the worked example for this job, with costs - [Compute](https://cloudlesslabs.com/stack/layers/compute/index.md): every tool in this layer - [APIs, queues and events](https://cloudlesslabs.com/stack/layers/api-events/index.md): every tool in this layer - [Data](https://cloudlesslabs.com/stack/layers/data/index.md): every tool in this layer - [Email and messaging](https://cloudlesslabs.com/stack/layers/email/index.md): every tool in this layer - [Observability](https://cloudlesslabs.com/stack/layers/observability/index.md): every tool in this layer - [Every use case and tool in one file](https://cloudlesslabs.com/stack/brief.md) - [Map of every Markdown file on cloudlesslabs.com, with what each one answers](https://ask.cloudlesslabs.com)