Changelog

Pause queues, read the whole attempt timeline

Queues can be paused and resumed without a restart, and sextant inspect now shows every attempt of a job on one timeline.

• New (beta): sextant queues pause <name> and sextant queues resume <name>, plus POST /v2/queues/{queue}/pause and /resume. Running jobs finish; nothing new starts. See Pause and resume a queue.
• New: sextant inspect <job-id> prints each attempt with its worker, duration, error and the backoff that followed.
• New: the Go SDK passes context.Context cancellation to handlers, so a cancelled job stops its work early.
• Fix: sextant logs --follow no longer drops lines when the server restarts mid-stream.
• Fix: the Postgres store no longer holds a long transaction while counting queue depth, which removed a source of lock waits on busy queues.

Schedules survive daylight saving changes

A patch release for schedule drift around DST changes and a stricter webhook signature check.

• Fix: a schedule in a time zone with daylight saving time ran one hour late on the first day after the clocks changed. Next runs are now computed from the wall-clock expression, not from the previous run plus 24 hours.
• Fix: sextant config check reported valid backoff.max values below backoff.base as correct. It now fails with a clear message.
• Security: webhook signatures now include the timestamp in the signed payload, and the SDKs reject deliveries older than five minutes by default. Update the SDK on the receiving side; see Webhooks.

Queue wait metrics and the overlap policy

A histogram for how long jobs wait in a queue, an overlap option for schedules, and an async Python client.

• New: the histogram sextant_queue_wait_seconds measures the time between a job becoming runnable and a worker starting it. It is the metric to alert on when workers fall behind. See Observability.
• New: schedules accept overlap = "skip" | "queue" | "allow". The default stays skip.
• New: the Python SDK ships AsyncSextant, built on asyncio, with the same methods as the synchronous client.
• New: sextant jobs list --state failed --since 1h filters by state and age.

Webhooks and scoped tokens

Job events can be pushed to your HTTPS endpoint with a signature, and API tokens carry scopes.

• New: webhooks for job.succeeded, job.failed, job.dead and job.cancelled, signed with HMAC-SHA256 and retried for 24 hours.
• New: tokens have scopes such as jobs:write and queues:read, and an optional expiry. Tokens created before 2.2 keep full access until you rotate them.
• New: sextant tokens create --scope jobs:write --expires-in 90d.
• Improved: the SQLite store enables write-ahead logging by default and no longer blocks readers during a checkpoint.

Jitter, the dead queue and live logs

Backoff gets jitter, hopeless jobs move to a dead state you can inspect, and logs can be followed from the CLI.

• New: backoff.jitter spreads retries so that a burst of failures does not return as a burst of retries.
• New: jobs that exhaust max_attempts move to dead instead of staying failed, and can be requeued with sextant jobs retry.
• New: sextant logs --follow --queue emails streams structured log lines from the server.
• Deprecated: the retry_delay option. Use backoff.base; retry_delay keeps working until 3.0.

Sextant 2.0

A new store layer, a versioned REST API, a TOML config file and one binary for server and worker.

• Breaking: the config file is now sextant.toml. sextant.yaml is no longer read. sextant migrate config converts it.
• Breaking: Redis is no longer a store. SQLite (one machine) and Postgres (many) replace it. sextant migrate from-v1 imports pending jobs and schedules.
• Breaking: the REST API moved from /api/v1 to /v2, with bearer tokens instead of the X-Sextant-Key header.
• New: sextant server and sextant worker replace sextant start.
• New: a Go SDK, next to Node and Python.
• New: idempotency keys on job creation.

The step-by-step path is in Migrating from v1.

Final maintenance release of v1

Security fixes and a Redis reconnect fix. Version 1 receives no further updates.

• Fix: workers reconnect after a Redis failover instead of exiting.
• Security: the v1 dashboard no longer echoes API keys in error pages.
• Deprecation: version 1 is end of life. Documentation stays available under v1.