not a good look the comment posted by OP here is also LLM written.

anyway, real feedback:

this is one of the longest existing unix service patterns ... what's this doing that the distro and usual suspects don't? (as a startup ISP in early 90's, we found what we needed already in BSD 3 distro)

to browse countless variants, swing by github, search terms like angel, daemon, dead man monitor, etc., although to be fair, most of those will long predate vibe coding, so this one may bring properties those don't

such a tool likely shouldn't be yet another separate SaaS, and the 'narrower' point is why: it should not feed that separate Saas (opposite of narrow), it should feed OTel, PagerDuty, whatever is your "broken things" sink, dash, and comms tree sender ... if you don't have that, do that first, then do this class of thing

When a background job dies, knowing that it stopped is usually easy. Figuring out what it was doing immediately before that is the frustrating part.

I built this to keep track of a worker that was stopping too often without an obvious reason and I had no idea what the job was doing when it stopped. Now, it's been for a few months with very successful results and I decided to make it available to everyone with a nice free tier. Capto watches heartbeats / cron / HTTP for background jobs, which can carry short breadcrumbs (structured notes, not a log dump). When the ping stops, those last notes are frozen onto the incident and ride along on the alert.

If you'd like to try it out, the link is a live demo on the real API — no account, no email. You get a ping URL for an hour. Curl it a few times, POST a breadcrumb, stop curling, wait. An incident opens with the context still attached.

It's deliberately narrow: not logs, not APM, not on-call. I'd love to get some feedback on it.