How it works
Automations fail silently. Each one got a URL to ping, and Checkilo sent an alert when a ping was late.
Each automation got a URLIntegrations for Zapier, Make and n8n.
It pinged that URLA worker scanned for missed pings every 30 seconds.
A late ping sent an alertTo the channels you chose.
- Slack
- Discord
- Telegram
- LINE
- Teams
- Webhook
Load test on production
k6 from a same-region Fly machine against the live service on 13 July 2026: eleven scenarios across two rounds. Five are shown here.
Cold spike0 of 12,706pings lost at 200 runs a second from idle. Cold start under 1 second.
Failure dedup2,400 → 1failures became one alert. p95 83 ms.
Baselinep95 77 msat 20 runs a second, 0% errors.
All five scenarios
| Scenario | Load | Result | Verdict |
|---|---|---|---|
| Baseline | 20 runs/s, steady | p95 77 ms, 0% errors | Pass |
| Cold spike | 200 runs/s from idle | 0 of 12,706 pings lost, cold start under 1 s | Pass |
| Failure dedup | 20 runs/s | 2,400 failures became 1 alert, p95 83 ms | Pass |
| Abuse wall | 200 req/s | 101/s admitted, 98/s rejected with 429, p95 65 ms | Pass |
| Soak | 30 runs/s for 1 hour | Stable for 22 minutes, then p95 27 s | Finding |
Where it broke
Finding
The soak test stopped being stable after about 22 minutes.
At 30 runs a second, p95 went from normal to 27 seconds when Fly's shared-CPU burst credits ran out. Sustained, the service handles 20 to 35 requests a second.
Nothing crashed and it recovered in under a second. The fix is a dedicated-CPU machine.
Why it closed
I optimised for scale before checking that people wanted the core feature.
I was passionate about making the system hold up at scale, and I overlooked whether the core feature was really wanted. The pain Checkilo solves turned out to be weak for how the app was positioned.
The result was over-engineering from the first MVP. I closed the app.