Introduction

Sextant runs background work and tells you what happened. You give it a job (a handler name and a JSON payload), a time, and a queue. Sextant stores the job, hands it to a worker, retries it when it fails, and keeps a record of every attempt.

It ships as one binary with two roles, a server (the HTTP API and the scheduler) and a worker (the process that runs your handlers), plus SDKs for Node, Python and Go.

What it is good at

• Delayed and recurring work. Send a receipt in ten minutes, rebuild a report every night at 02:00 in your customer’s time zone.
• Retries you can explain. Attempts, backoff and jitter are per-queue settings, and every attempt is recorded with its error.
• Seeing what ran. Metrics, structured logs and a timeline per job come with the server. No separate agent.
• Small footprint. SQLite for one machine, Postgres when you need several servers. No broker to operate.

What it is not

Sextant is not a workflow engine. A job is one unit of work with no built-in branching or fan-out. If you need to chain jobs, create the next job from the handler of the previous one, as described in Core concepts.

How these docs are organized

Press Ctrl K (or ⌘ K) anywhere to search. The same content is available to AI tools at /llms.txt.