Get a push notification when your server needs you

Between "I'll check the dashboard" and a paid pager

There's a wide gap between eyeballing Grafana when you happen to remember and paying for a full incident platform with on-call rotations. For a side project, a single VPS, or a small fleet, that middle ground is exactly one thing: tell my phone when a number crosses a line. Lert fills it. You write the threshold logic — you know your workload better than any anomaly detector — and Lert handles the "get it to my pocket" part.

The one-line version

Lert gives you a unique URL. When your check trips, POST to it:

curl -X POST "https://lert.dev/p/your-id" \
  -H "Content-Type: application/json" \
  -d '{"title":"⚠️ web-01 CPU 96%","body":"5-min load 8.2 · investigate","tag":"monitor"}'

No auth token, no SDK, no agent daemon. The rest is just deciding when to send it.

A small monitoring loop

1. Copy your Lert URL

Grab your endpoint from the Lert app — https://lert.dev/p/your-id — and keep it in an env var. Treat it like a password.

2. Measure, compare, alert

This checks CPU every 60 seconds and only alerts once per incident by remembering the last state in a file — so a sustained spike buzzes you once, not sixty times:

#!/usr/bin/env bash
URL="https://lert.dev/p/your-id"
STATE=/tmp/cpu.state
LIMIT=90

while true; do
  # idle % from top → used % = 100 - idle
  USED=$(top -bn1 | awk '/Cpu\(s\)/{print 100 - $8}' | cut -d. -f1)
  LAST=$(cat "$STATE" 2>/dev/null || echo ok)

  if [ "$USED" -ge "$LIMIT" ] && [ "$LAST" = ok ]; then
    echo alerting > "$STATE"
    curl -sX POST "$URL" --data-binary "⚠️ $(hostname) CPU ${USED}% — over ${LIMIT}%" \
      -H "Content-Type: text/plain"
  elif [ "$USED" -lt "$LIMIT" ] && [ "$LAST" = alerting ]; then
    echo ok > "$STATE"
    curl -sX POST "$URL" --data-binary "✅ $(hostname) CPU back to ${USED}%" \
      -H "Content-Type: text/plain"
  fi
  sleep 60
done

3. Health checks for the things that go all the way down

Thresholds catch a struggling server; a health check catches a dead one. Run this from a different machine so it still works when the target is unreachable — curl the endpoint, and if it doesn't answer with 200, buzz your phone:

CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 \
  "https://api.example.com/health")

if [ "$CODE" != "200" ]; then
  curl -sX POST "https://lert.dev/p/your-id" \
    -H "Content-Type: application/json" \
    -d "{\"title\":\"🔴 API down\",\"body\":\"health check returned $CODE\",\"tag\":\"uptime\"}"
fi

Run either script from cron (say every minute) or leave the loop running under systemd. When something crosses a line, you get a real iOS push — it wakes a locked phone and buzzes a paired Apple Watch, usually within a second.

Keep the signal clean

• Alert on transitions, not states. The state file above is the whole trick — one buzz when it breaks, one when it recovers, silence in between.
• Put the number in the title. "CPU 96% on web-01" tells you everything from the lock screen; you decide whether to reach for the laptop before you even unlock.
• Monitor from outside for downtime. A box can't tell you it's down. A second machine can.

Why Lert for server alerts

Monitoring stacks are powerful and heavy — agents to install, endpoints to secure, dashboards to maintain, seats to pay for. For a lot of servers that's overkill; you just want a buzz when a number goes wrong. Lert is that buzz with no infrastructure: one HTTP request from a shell script you already understand. The endpoint URL is the authentication, so your server can call for help with zero setup.