Every outage I've debugged in the last year had the same root: we deployed and walked away. The deploy went green, so everything must be fine, right?
No. Here's the 3-line probe that runs before (and after) every deploy in my stack:
import requests, sys
r = requests.get(f"https://{sys.argv[1]}/health", timeout=10)
assert r.ok and r.json().get('status') == 'ok', f"DEPLOY HALTED: {r.status_code}"
print("healthy, deploying")
Why 3 lines beat a monitoring stack (at first)
Last month this caught 7 incidents:
-
3x stale cache —
/healthreturned 200 from a worker holding old code. Fixed by adding a build-hash field to the response. -
2x connection pool exhaustion — 200 on
/health, but real traffic 502'd. Fixed by probing a DB-touching endpoint too. - 2x bad TLS renewal — cert was about to expire, probe caught the degraded chain before browsers did.
The lesson: your health endpoint lies. Make it tell the truth:
{"status": "ok", "build": "a91f3c", "db": "ok", "version": "2.4.1"}
The monitor layer
Once the probe is honest, run it from outside every 5 minutes from a cheap VPS:
*/5 * * * * /usr/bin/python3 /opt/health/probe.py hive80lab.gumroad.com || curl -s -X POST "$SLACK_WEBHOOK" -d '{"text":"SITE DOWN"}'
That's a full uptime monitor. I cancelled my $29/mo monitoring subscription after this ran for two weeks without a missed alert.
If you want the full kit — 40+ production automation scripts covering health checks, cron guards, log rotation, and self-healing restarts — it's pay-what-you-want here:
Run it before your next deploy. Thank yourself later.
Top comments (0)