Vault Inc

Product

Four moving parts, and no cron box.

Vault Inc is a queue, a scheduler, a retry engine and a run log. You keep your workers, your database and your secrets; it keeps track of what ran.

Queues

Answer the request, do the work after

A queue is the shortest path between a fast response and slow work. Post the job, get an id back in single-digit milliseconds, and let Vault Inc worry about when it runs.

  • Priority lanes, so a password reset never queues behind a nightly import
  • Concurrency keys cap simultaneous runs per customer, per tenant, per anything
  • Idempotency keys make a double submit harmless
POST /v1/jobs
curl https://api.vaultinc.dev/v1/jobs \
  -H "Authorization: Bearer $VAULTINC_KEY" \
  -d '{
    "job": "send-receipt-email",
    "args": { "order": "ord_8812" },
    "idempotency_key": "ord_8812:receipt"
  }'

# 202 Accepted
# { "id": "run_3f9a", "state": "queued" }

Schedules

Cron, with a timezone that behaves

Recurring work is where most homegrown runners quietly break: the clocks go back, two workers wake at once, and the nightly import runs twice. Vault Inc holds a single lock per schedule and skips rather than overlaps.

  • Standard cron expressions, evaluated in the timezone you name
  • Overlap policy per schedule: skip, queue, or cancel the run in flight
  • A schedule that misses its window tells you, instead of failing silently
schedules.yml
nightly-usage-rollup:
  cron: "0 2 * * *"
  timezone: Europe/London
  overlap: skip
  timeout: 15m

post-webhook-delivery:
  cron: "*/5 * * * *"
  timezone: UTC
  overlap: queue

Retries and backoff

Fail once, not forever

Most failures are temporary and a few are permanent, and treating them the same is what turns a blip into an outage. Set a policy per job, and let anything that exhausts it fall into a dead letter queue you can actually read.

  • Exponential, linear or fixed backoff, with jitter on by default
  • Non-retryable status codes stop immediately instead of burning attempts
  • Drain the dead letter queue back into the main one once you have a fix
backoff schedule, 6 attempts
attempt 1 immediate
attempt 2 2s
attempt 3 4s
attempt 4 8s
attempt 5 16s
attempt 6 32s

Run history

Proof, not vibes

Every attempt keeps its arguments, its output, its duration and the worker that took it. When someone asks whether the export really ran on the 3rd, the answer is a link rather than a search through logs.

  • Thirty days of history on every plan, longer on Scale
  • Filter by job, state, customer or any argument you indexed
  • Replay a single run with its original arguments, untouched
run_3f9a
run_3f9a  send-receipt-email
  state     completed
  queued    2026-08-30 14:02:11.204Z
  started   2026-08-30 14:02:11.242Z
  finished  2026-08-30 14:02:12.108Z
  duration  866ms
  worker    eu-west-1 / wkr-07
  attempts  1

It takes about ten minutes to move your first job.

Point Vault Inc at an endpoint you already have and enqueue something small.

Back to GSAP Vault