Wakeplane
Durable scheduling control plane for long-running systems.
alpha · 0.1.0
Wakeplane decides when work is due, records the occurrence durably, dispatches execution through typed targets, and keeps an append-only ledger of what happened.
What it is
Section titled “What it is”Wakeplane is a scheduling control plane, not a thin wrapper around cron.
Cron is one schedule input. The control plane above it is the product.
| Responsibility | Wakeplane |
|---|---|
| Schedule types | cron, interval, once |
| Timezone awareness | Required, persisted |
| Occurrence identity | Deterministic — no duplicates |
| Run recording | Durable before execution |
| Retries & backoff | Policy-driven |
| Missed-run handling | Configurable misfire behavior |
| Overlap & concurrency | Per-schedule policy |
| Run ledger | Append-only |
| Executor targets | Typed (HTTP, shell, in-process workflow) |
| Operator surface | HTTP JSON API + Cobra CLI |
Status alpha
Section titled “Status ”Wakeplane is pre-stable. The core control plane works and is tested.
What ships today:
- Single-process Go daemon and CLI (
wakeplane/wakeplaned) - SQLite-first storage with embedded migrations
- Planner and dispatcher loops
- HTTP, shell, and in-process workflow executors
- HTTP JSON API with cursor-based pagination
- Metrics, health, readiness, and status endpoints
- Structured shutdown and drain logging
Not yet available:
- Postgres storage (SQLite-first; Postgres seam is designed)
- Auth, RBAC, multi-tenancy
- Distributed coordination
- UI
- Plugin loading
Use Wakeplane today if you need a reliable, embedded scheduler for internal systems and are comfortable operating pre-stable software.
How it works
Section titled “How it works”schedule definition → planner → due occurrences → dispatcher → executor → run ledger- Schedule definitions are persisted with typed schedule and target specs.
- The planner computes due occurrences from
next_run_at, timezone, and policy. - Due occurrences are materialized with deterministic occurrence keys — duplicates are impossible.
- The dispatcher claims eligible runs, renews leases, and dispatches execution.
- Executors record results and receipts. Every attempt is in the ledger.
Design constraints
Section titled “Design constraints”These are hard constraints, not options:
- Execution does not happen without a durable run record and claim.
- Duplicate execution for the same occurrence key is not permitted.
- Schedule timezone is required persisted state — not optional metadata.
- Scheduler and dispatcher concerns are separated.
- The run ledger is append-only.
Built by Justyn Clark Network