Background jobs, retries you can defend, failures the dashboard surfaces.
Background jobs are the part of the product that goes wrong in ways no one notices. We build queues with explicit retry policies, idempotent handlers, dead-letter queues for the genuinely broken work, and dashboards that surface what's running, what's stuck, and what failed. The ops team sees the truth; the product team stops finding out about issues from support tickets.
What we build
A queue tier built for production, not for the demo
Per-job timeouts, configurable concurrency per queue, rate-limited workers where downstream APIs need it, and a separation between the queue layer and the source-of-truth database, so a backed-up queue never corrupts your data.
Idempotent handlers as the default
Every handler is safe to run twice. State changes are dedupe'd on a job-derived key. A retry storm doesn't corrupt the database; a manual replay during incident response doesn't either.
Retry policies, not retry hope
Per-job retry counts, exponential backoff with jitter, and explicit handling for retryable vs non-retryable errors. A 429 from a vendor retries; a 400 doesn't. The policy is documented in the job definition, not learned the hard way.
Dead-letter queues that someone reads
Jobs that exhaust their retries land in a DLQ with the full payload, error chain, and timestamps. The DLQ has a UI, an owner, and an SLA. It's not where jobs go to die quietly.
Observability via error tracking + queue dashboard
Every handler is instrumented; failures get full stack traces with the job payload. The queue dashboard shows current depth per queue, lag, and recent failures. Production isn't a black box.
Scheduled jobs as code
Cron-shaped work is defined alongside the queue, version-controlled, and visible. No 'who set up that cron on the box' surprises. Recurring backups, reconciliations, and digest emails all run through the same scheduler the rest of the queue uses.
Where this fits
Your product has been shipping background work via setTimeout or unmanaged crons and it's starting to bite.
You have a queue but no observability into what's stuck, and you find out about it when a customer asks why their export didn't arrive.
You're integrating with three vendor APIs, each rate-limited differently, and the current code lives in one handler that throws when any of them is slow.
Tech stack
- TypeScript
- BullMQ
- Redis
- Postgres
- Sentry
Want this for your team?
30 minutes to scope what you need. No pitch deck, no obligation. We tell you straight whether Stacklane fits.
Book a Free Call