GoBeep — cron job (and AI agent) monitoring for indie devs
What it is
GoBeep is dead-simple monitoring for anything that's supposed to run on a schedule — cron jobs, background workers, and now AI agent loops too. You add one line to the end of the job. If it doesn't check in when it's supposed to, you get alerted by email or Slack. That's the whole product.
Why I built it
I found out one day that my nightly backup job had been failing silently for 4 days. No crash, no error, no alert — it just stopped running, and I only found out by accident. The worst part was realizing this wasn't the first time it had happened, just the first time I'd noticed.
A cron job that fails loudly shows up in your logs. A cron job that fails silently doesn't show up anywhere. You find out from a customer, or you don't find out at all. That gap — between "the job is scheduled" and "the job actually ran" — is what GoBeep monitors.
The same gap exists with AI agents now too. An agent can report "done" without the underlying task actually completing — it's the same failure mode as a cron job that silently stops, just with a more convincing voice attached to it. So GoBeep watches both.
How it works
Create a monitor in GoBeep, get a ping URL back, and call it at the end of your job:
await fetch(process.env.GOBEEP_PING_URL)
Works in any language, any platform — Railway, Render, Fly.io, bare cron, a Lambda, an agent's final step. If the ping doesn't arrive within the expected window (with a grace period so normal scheduling jitter doesn't trigger false alarms), you get beeped.
Tech stack
- Frontend/backend: Next.js (App Router)
- Database: PostgreSQL via Prisma
- Scheduler: the checker itself runs in-process with
node-cron, guarded by a Postgres advisory lock (pg_try_advisory_lock) so it's safe even if I scale to multiple instances - Auth: Clerk
- Email alerts: Resend
- Slack alerts: incoming webhooks, no bot/OAuth setup needed
- Payments: Paddle
- Hosting: Dockerized, deployed on Railway — this matters more than it sounds like it should, since the in-process scheduler needs a host that keeps the container alive, which rules out serverless platforms entirely
Lessons from the build
The hardest part wasn't the alerting — it was the grace period. Cloud platforms add 10–30 second delays to scheduled jobs. Too strict and you get false alarms at 2am; too loose and real failures slip through. Getting that balance right took more iteration than anything else in the product.
The other thing I didn't expect: building this solo around a full course load means the actual constraint isn't ideas, it's hours. Every feature had to earn its place.
Happy to answer questions about the tech, the indie-dev-vs-AI-agent angle, or just building this around a CS degree.
gobeep.xyz if you want to try it.
The grace period lesson stood out to me. It's one of those details that sounds minor until you build it yourself—too strict and users lose trust because of false alarms, too loose and the product misses the failures it exists to catch. That's a much harder problem than sending notifications.
Yeah, this was the part that took the most iteration by far. Sending an alert is trivial — deciding when a missed check-in is actually a missed check-in is the hard part.
What ended up working: making the grace period configurable per monitor instead of one global setting. A job that's supposed to run every minute needs a much tighter window than a nightly backup — treating them the same was where most of the false alarms came from early on.
Curious if you've run into the same tradeoff anywhere else — feels like the kind of problem that shows up in any "did this actually happen" system, not just cron monitoring.
That's exactly what I was curious about.
Your reply made me think about one implication that goes quite a bit beyond the grace period itself, but it's probably too much to unpack properly in a thread.
Happy to explain what I mean if it's useful. What's the best email to reach you on?
Happy to hear it — if it's something concrete, just drop it here. Easier for others following the thread to get value from it too.
I thought about that.
The reason I hesitated is that I don't think it's the kind of point that's useful when compressed into a few comments. Stripped of the reasoning behind it, it's too easy to either sound obvious or simply wrong.
I'd rather leave your thread focused on the discussion you've started than derail it into something much broader.
No worries — appreciate you thinking it through either way. If it ever turns into something concrete, happy to pick it back up.
Fair enough.
The short version is this:
I don't think the interesting question is where the grace period should be.
I think it's how much of your product should rely on system inference versus explicitly asking users to define intent. That decision quietly shapes much more than alert accuracy over time.
That's why I thought the implication was much broader than cron monitoring itself.
Worth being precise here — the grace period isn't inference, it's slack around something the user already stated explicitly (their expected schedule). GoBeep doesn't guess intent anywhere in that flow. So I don't think this surfaces a hidden tradeoff for this particular product — might apply elsewhere, but not here.
That's a fair distinction, and I think you're right to call it out.
I was treating the grace period as an inference problem when it's really user-defined tolerance around explicit intent.
The broader question I was trying to get at is probably a different one entirely, so I'd rather rethink it than force the wrong framework onto your product.
Appreciate the correction.
This comment was deleted 3 months ago