Why We Built JustRun

Every developer has a cron job story. Maybe it is the backup script that silently stopped running three months ago. Maybe it is the invoice sync that fails every other Tuesday because of a rate limit nobody noticed. Or maybe it is the deployment webhook that worked perfectly in staging but never fired in production because someone forgot to update the URL.

We have lived all of these. At BuiltByGo, we manage dozens of WordPress and SaaS applications, each with their own set of scheduled tasks. For years we relied on a patchwork of server crontabs, EasyCron subscriptions, and the occasional AWS Lambda with a CloudWatch rule. It worked, mostly. But “mostly” is a dangerous word when you are talking about production infrastructure.

The problem is not scheduling

Triggering an HTTP request on a timer is a solved problem. Any VPS with cron installed can do it. The real problems start after the request fires:

• Visibility. Did the job actually run? What was the response code? How long did it take? Most cron setups give you nothing unless you build logging yourself.
• Failure handling. When a job returns a 500, what happens? On a raw crontab, nothing. The error vanishes into syslog. You find out days later when a customer complains.
• Alerting. Even if you pipe cron output to email, the signal-to-noise ratio is terrible. You either get flooded with success emails or you miss the one failure that matters.
• Debugging.A job failed at 3am. The response body says “Internal Server Error.” Now what? You open your APM, grep your logs, and piece together what happened. That is 30 minutes of toil for every incident.

What we wanted

We wanted a single dashboard where every scheduled task across every project is visible. We wanted to see success rates, response times, and failure trends at a glance. We wanted retries that actually work, with configurable backoff strategies, not just “run it again in a minute and hope for the best.”

Most importantly, we wanted AI-powered diagnostics. When a job fails, we do not want to read raw logs. We want a plain-English explanation of what went wrong and a suggested fix. That is the feature that tipped us from “we should use an existing service” to “we should build this ourselves.”

The technical bet

JustRun is built on Hono for the API layer, giving us 150,000 requests per second per core. The scheduler uses an in-memory priority queue with a one-second tick loop, not database polling. Messages flow through NATS JetStream for durable, at-least-once delivery. The frontend is Next.js 15 with React Server Components for fast initial loads and real-time updates via WebSocket.

We chose this stack because we have seen what happens when cron services are built on PHP and MySQL polling. They work fine at 100 jobs. At 10,000 jobs they start missing schedules. At 100,000 they fall over entirely. We wanted an architecture that scales linearly from day one.

What comes next

JustRun is currently in public beta. The core scheduling, monitoring, and alerting features are production-ready. AI diagnostics ship with every plan. We are working on job chains, team workspaces, and a public API with MCP support so AI agents can manage cron jobs programmatically.

If you have ever lost sleep over a failed cron job, we built this for you.