Introduction

SchedStack is durable scheduled HTTP delivery. You hand it a destination and a time — one-shot or recurring — and it owns everything from accepting the request to confirming delivery: retried until it lands, never silently lost.

It runs as one static binary plus a Postgres URL. It’s the durable timer that stateless agents and functions can’t hold on to themselves — durable scheduling for the agentic era.

# A destination + a time. That's the whole API.
curl -X POST https://api.schedstack.com/v1/schedules \
  -H "Authorization: Bearer sk_test_…" \
  -H "Content-Type: application/json" \
  -d '{"endpoint": "https://example.com/hook", "delay": "24h"}'

In 24 hours, SchedStack signs and POSTs to your endpoint. If it fails, SchedStack retries on a backoff. If it exhausts retries, the delivery lands in your dead-letter view — not in the void.

The four pillars

Agent-native

A first-class MCP server with forgiving timing inputs — a duration ("in 2h"), an ISO 8601 / RFC 3339 time, or cron — so agents can schedule deliveries and preview the next fire times before committing.

A primitive, not a platform

One durable scheduling primitive — simple to adopt, easy to reason about. No workflow DSL, no orchestration runtime, no background workers for you to operate.

Spec-first DX

A spec-first REST API, a sched CLI, and an interactive reference you can call live. The same engine runs managed and self-hosted — one binary, one Postgres URL.

Trust — no silent loss

Every accepted delivery either succeeds or becomes visible in your dead-letter view. Deliveries are signed when a signing secret is configured; every request carries a stable idempotency key.

The guarantees

Two guarantees define the contract. Read both before you build against it — the second one has a tradeoff you own.

No silent loss

Once SchedStack returns 201 for a schedule, that delivery is durable. It will succeed, or it will end up in your dead-letter view where you can inspect every attempt and replay it. A delivery never disappears between “accepted” and a terminal outcome.

At-least-once, made safe — you dedup

SchedStack delivers at least once. Retries, failover, and reclaim after a node restart mean your endpoint can receive the same delivery more than once. That is by design: choosing at-least-once over at-most-once is what makes “never silently lost” possible.

Two mechanisms make redelivery safe, and using them is your responsibility:

• Sched-Signature — when a signing secret is configured (on the endpoint profile, or as a project default), each request is HMAC-signed (t=…,v1=…) with that endpoint or project secret, alongside a Sched-Timestamp. Verify it to confirm the request came from SchedStack and is not replayed. Without a configured secret, deliveries are sent unsigned with no Sched-Signature header. See Verify signatures.
• Idempotency-Key — every request carries a stable key (also Sched-Delivery-Id). Dedup on it so a redelivered request is a no-op on your side.

At-least-once means you dedup

SchedStack does not guarantee exactly-once delivery — no networked system honestly can. Make your endpoint idempotent: verify the signature, then key on Idempotency-Key. This is the single most important thing to get right.

The accuracy SLO: 100–300 ms, dispatch-initiation

SchedStack publishes a 100–300 ms p99 dispatch-initiation SLO. Read that phrase literally:

• Dispatch-initiation, not delivery completion. It measures first byte out − scheduled time — when SchedStack starts the outbound request, not when your endpoint finishes responding. Network and your server’s latency are outside it.
• Live first-attempts only. The published number is computed over first attempts (Sched-Attempt: 1) in live mode. It excludes retries, reclaim/recovery fires, breaker/budget deferrals, and sub-floor near-instant schedules.

Tip

SchedStack controls initiation precisely; it does not control your receiver’s response time. Build for the guarantee you actually get: prompt, accurate dispatch — plus retry-until-it-lands for everything after the first byte.

Where to go next

Quickstart

Schedule your first durable delivery and watch it land, in under five minutes. Start here →

Core concepts

Schedules, deliveries, attempts, retries, dead-letter, and replay — the model behind the API. Read the model →

Verify signatures

Validate Sched-Signature and dedup on Idempotency-Key — the safe at-least-once recipe. Verify deliveries →

MCP server

Let agents schedule, preview, and replay deliveries over MCP. Connect an agent →

API reference

The full /v1 surface — schedules, deliveries, attempts — interactive and live. Open the reference →

Design-partner phase

SchedStack is live in production and onboarding design partners by hand. There’s no self-serve signup yet — keys are issued directly. If you have an sk_test_… or sk_live_… key, the Quickstart is everything you need to reach your first delivery.