MediumReliability

Background jobs that fail silently

Emails, invoices, syncs or clean-ups quietly stop for some or all users, and you find out weeks later from a customer rather than from the system. Whether the app keeps working when something fails. Check it yourself with the steps below; our test adds what a script and a second account can find.

What it looks like

// app/api/sync/route.ts, run hourly via vercel.json crons
export async function GET() {
  for (const u of await db.users()) await syncStripe(u); // one throw ends the run
  return Response.json({ ok: true });
}

An hourly job that walks every user in one loop; one failure stops the rest, nothing records what was skipped, and the platform does not retry.

What happens

Emails, invoices, syncs or clean-ups quietly stop for some or all users, and you find out weeks later from a customer rather than from the system.

Where it shows up

Descriptive, not a verdict: builders and stacks whose defaults make this reachable, or that a public incident names. Each hub states the tool's own security features.

Check it yourself

Uses your builder's dashboard and your browser. No tools to install.

List every scheduled or background task your app has: on Vercel open Settings then Cron Jobs; on Supabase open Integrations then Cron, and Edge Functions; on Replit look for a Scheduled deployment.
For each one, open its logs (on Vercel, "View Logs" next to the job) and read the last few runs.
Ask two questions per job: if one run fails, does anything record it or retry it, and if it runs twice, does it do double work (two emails, two charges)?

Bad result: runs with red errors and no follow-up, gaps where a scheduled run never appears, or a job you cannot answer those two questions for.

What we check

We trigger each job with one record made to fail and check whether the remaining records are still processed. We also check whether the failure is recorded anywhere a person would see it, and whether running the job twice duplicates side effects. The report lists each job with its failure and duplicate behaviour.

Fix direction

Process records one at a time with their own try and catch, record each failure with the record id, and make every run safe to repeat, which Vercel's cron docs call idempotent and reconciliation-based. For work that must not be lost, put it on a queue with a visibility window and retry, such as Supabase Queues, rather than a bare cron loop.

Mechanism documented in: Vercel: Managing Cron Jobs (verified 2026-09-21); Supabase Queues (verified 2026-09-21).

Covered by

Pre-launch check ($490, 48 hours) and Full audit ($1,900, 5 business days)

Both include a re-check after your fixes.

Compare packages

Related patterns

Retries with no pause and no capReliability
One outage turns into a flood of retries from every open browser tab, which keeps the service down longer, runs up usage bills and can submit the same order or payment twice.
Medium
No idempotency on payment handlersPayments
A customer is charged twice after a network hiccup, or a replayed webhook tops up an account again and again for a single payment.
High
One process, one machine, nothing restarts itReliability
An unhandled error, an out-of-memory crash or a host reboot takes the whole app offline, and it stays offline until a person logs in and starts it again, often after customers have already emailed.
Medium
Stripe webhook accepted without signature verificationPayments
Anyone who finds the webhook URL can post a made-up payment-succeeded event and get an order fulfilled or a plan activated for a user of their choosing, without paying.
Critical

Questions

does vercel retry a failed cron job

No. Vercel's cron documentation states that it will not retry an invocation if a cron job fails, and that delivery is best effort, so a scheduled run can occasionally be missed or invoked twice. Your job has to record its own failures and catch up on the next run.

how do i know if my scheduled job is failing

Open the job's logs in your platform and read the last few runs, looking for errors and for gaps where a run should appear. Then check whether the job writes anything you would see, such as a row in a job_runs table or an alert. A job whose only sign of failure is a log line nobody reads is failing silently.

what does idempotent mean for a background job

Idempotent means running the job twice has the same effect as running it once. Vercel's docs give the example of "set user status to active" (safe to repeat) against "increment user credit" (doubles on a repeat). Track which records were already handled and check state before changing it, so a duplicate or missed run does no harm.

Back to the catalogue, or run the self-check for your stack.