Job Scheduler

Every app eventually needs a worker. You save a thing, and then something else has to happen. Call an API. Generate content with an LLM. Send an email. Charge a card. The classic move is to add Redis, pick a queue library, stand up a worker process, and wire webhooks back to the client so the UI can show a spinner.

That is a lot of plumbing for "run this after the save." sp00ky ships a scheduler that uses the database you already have. No extra servers. No webhook glue. No spinner you have to hand roll.

Write a row, not a worker

Jobs in sp00ky are just rows in your database. Call one function, a row appears, and the scheduler takes it from there. Your frontend watches the row the same way it watches anything else, so the loading state, the success state, and the failure state are a single query away.

If your server dies mid write, nothing leaks. If the user reloads the tab, the job keeps going. If the network flakes, it retries. The boring things that take an afternoon to get right are the default.

Retries that make sense

Some work is safe to retry a hundred times. Other work, like charging a card, cannot be retried even once. sp00ky lets you say which is which, in one line, per job. Everything else is automatic.

When something does go wrong, the error shows up on the job itself, in plain language. No log scavenger hunt. No mystery state. You read what happened.

Keeps itself honest

The scheduler notices when a worker stops answering and quietly hands its jobs to a healthy one. It checks that your backends are actually up before sending them traffic. It keeps score so your dashboards can keep score too.

You do not have to babysit any of it. That is the point.

How it stacks up

sp00ky's scheduler is deliberately small. It does one thing very well and cheerfully points you elsewhere when you need something bigger.

When to pick something else

Being honest about this is more useful than pretending sp00ky replaces everything. Temporal is the grown up answer for real workflows with sagas, replay, and human in the loop. Inngest is lovely when your work is a sequence of steps with per step retries. Trigger.dev is a nicer fit for long tasks you want to checkpoint. BullMQ, Sidekiq, and Celery are fast and battle tested if you already live in that ecosystem.

sp00ky is the right call when your background work looks like "call an endpoint with retries" and you want the UI to watch the result without you inventing a webhook bus for the third time this year. For anything bigger, trigger a real orchestrator from a sp00ky job. We will not be offended.