IoT heartbeat monitoring: know when your devices go silent

AWS IoT Events is dead. Now what?

Amazon quietly announced that AWS IoT Events reaches end-of-life on May 20, 2026. No new customers since 2024. Existing customers have been told to migrate — but migrate to what?

If you were using IoT Events primarily for device heartbeat detection — "alert me when device X stops reporting" — you were paying for a jet engine to blow out a candle. IoT Events was a complex state machine service. Heartbeat monitoring is a timer that resets on each ping.

Teams are scrambling to rebuild this on IoT Core with custom Lambda functions, Step Functions, or third-party IoT platforms that cost $500+/month. But for the heartbeat use case specifically, there is a dramatically simpler path.

The heartbeat pattern in 30 seconds

Every monitoring engineer knows this pattern. It is the simplest form of health checking:

That is it. No MQTT topics, no IoT Core rules, no state machine definitions, no CloudFormation templates. A device that can make an HTTP request can send a heartbeat.

Why traditional monitoring doesn't work for IoT

Datadog, New Relic, Grafana Cloud — they all assume you can install an agent on the target machine. The agent collects metrics, streams telemetry, and maintains a persistent connection to the monitoring backend.

IoT devices break every one of those assumptions:

• - A Raspberry Pi running a kiosk app has 512MB of RAM. A Datadog agent uses 200MB.
• - POS terminals run locked-down embedded Linux. You cannot install arbitrary binaries.
• - Industrial sensors on cellular modems pay per megabyte. Streaming telemetry is expensive.
• - Edge compute nodes behind NAT or VPN can't accept inbound connections for pull-based monitoring.
• - Battery-powered devices wake up, do work, and go back to sleep. No persistent agent possible.

The heartbeat model inverts the relationship. Instead of the monitoring system pulling from the device, the device pushes to the monitoring system. One outbound HTTP request. No agent, no SDK, no open ports.

Implementation: 3 lines on any device

Every Uptrack heartbeat monitor gives you a unique ping URL. The device hits it on a schedule. Here is what that looks like:

# Bash — works on any Linux device with curl
# Add to crontab: */1 * * * * /usr/local/bin/heartbeat.sh

#!/bin/bash
curl -fsS -m 10 -o /dev/null \
  https://uptrack.app/api/heartbeat/hb_abc123def456

Python on a Raspberry Pi:

import requests, time

HEARTBEAT_URL = "https://uptrack.app/api/heartbeat/hb_abc123def456"

while True:
    try:
        requests.get(HEARTBEAT_URL, timeout=10)
    except Exception:
        pass  # Next ping will succeed — or Uptrack alerts
    time.sleep(60)

Arduino / ESP32 with WiFi:

#include <WiFi.h>
#include <HTTPClient.h>

void sendHeartbeat() {
  HTTPClient http;
  http.begin("https://uptrack.app/api/heartbeat/hb_abc123def456");
  http.GET();
  http.end();
}

If the device can reach the internet, it can send a heartbeat. No libraries, no authentication tokens, no SDK versioning headaches.

Real-world use cases

The MQTT gateway pattern

Many IoT deployments use MQTT as the device-to-cloud transport. Devices publish sensor readings to an MQTT broker (Mosquitto, EMQX, HiveMQ). They do not speak HTTP natively.

The solution: use your MQTT gateway as a health check proxy. The gateway already aggregates device messages. Add a simple rule — when the gateway processes messages from a device, it pings that device's heartbeat URL.

# Node-RED function node or simple MQTT subscriber
# Subscribe to device topics, forward heartbeats to Uptrack

import paho.mqtt.client as mqtt
import requests

DEVICE_HEARTBEATS = {
    "factory/sensor/temp-01": "https://uptrack.app/api/heartbeat/hb_temp01",
    "factory/sensor/temp-02": "https://uptrack.app/api/heartbeat/hb_temp02",
    "factory/sensor/vibr-01": "https://uptrack.app/api/heartbeat/hb_vibr01",
}

def on_message(client, userdata, msg):
    url = DEVICE_HEARTBEATS.get(msg.topic)
    if url:
        requests.get(url, timeout=5)

client = mqtt.Client()
client.on_message = on_message
client.connect("localhost", 1883)
client.subscribe("factory/sensor/#")
client.loop_forever()

Now every MQTT device has heartbeat monitoring without any firmware changes. The gateway acts as a translation layer — MQTT in, HTTP heartbeat out. If a sensor stops publishing, its heartbeat timer expires and Uptrack fires an alert.

How Uptrack heartbeat monitoring works

When you create a heartbeat monitor in Uptrack, you get a unique URL and configure two parameters:

The lifecycle is straightforward:

Device pings URL ──→ Timer resets to (interval + grace)
                       │
                       ├── Next ping arrives in time ──→ Timer resets again ──→ ✅
                       │
                       └── No ping within window ──→ Status: DOWN
                                                     │
                                                     └── Alert via Slack / Discord
                                                         / email / webhook

Device comes back ──→ Pings URL ──→ Status: UP ──→ Recovery alert

Each heartbeat monitor runs as a lightweight BEAM process on Uptrack's servers. No polling, no cron — the process holds an in-memory timer and reacts instantly when a ping arrives or a deadline passes.

Migrating from AWS IoT Events in an afternoon

If you were using IoT Events for heartbeat detection, here is the migration path:

What you had before:

Device → MQTT → IoT Core Rule → IoT Events Detector Model
         → Lambda → SNS → PagerDuty

6 AWS services. $0.25/million messages + $0.10/detector/month
+ Lambda invocations + SNS + your sanity.

What you have after:

Device → curl → Uptrack → Slack

1 HTTP request. Free for 50 devices.

No IAM roles, no VPC endpoints, no CloudWatch alarms to monitor the monitoring. The device makes an HTTP GET. If it stops, you get alerted.

Scaling to thousands of devices

A common concern: "I have 2,000 sensors. Won't that be 2,000 monitors?" It depends on your failure model.

If individual sensor failure matters — a freezer temperature sensor in a vaccine storage facility, for example — yes, each sensor gets its own heartbeat monitor. You need to know which specific device went silent.

If sensors fail in groups — all sensors on one factory floor share a gateway, all kiosks in one store share a network — monitor the gateway or the network, not each device individually. One heartbeat monitor per gateway covers dozens of downstream devices.

For large fleets, the heartbeat URL can also carry a payload. Append status information as query parameters — battery level, firmware version, error counts — and the ping doubles as a lightweight telemetry beacon.