0 2 * * * run_invoices.sh
This line has no idea what it depends on.
It fires at two, whether or not the subscriptions it needs finished loading. Below is the path from that line to a governed, evidence-backed run — and the three surfaces it can run on. The script stays untouched.
01 · The path
The Weev agent · UpcomingObserve. Adopt. Own. Native.
Four rungs, chosen per job. Every rung produces the same run record with a stated origin — and every step has a mechanical rollback.
$ weev-agent enroll --token wv_7f2a service installed · outbound 443 only discovered 41 jobs (sql-agent 28, tasks 13) streaming runs · hash chain intact
What changed
A read-only change ticket, one install. Weev becomes the long-term history the box never kept — tamper-evident from the point of capture.
02 · Where it runs
Three surfaces, one graph
No new queue, no new scheduler, nothing to migrate onto. Your work runs where it runs today — on a host only your network can see, inside a service you deploy, or behind an endpoint you already have.
The Weev agent
UpcomingObserves and escalates the jobs your schedulers already run. The direction we're building — designed, not shipped.
$ weev-agent enroll --token wv_7f2a outbound 443 only · no listener discovered 41 jobs · streaming runs
What it puts in reach
- SQL Server Agent and Task Scheduler
- scripts on locked-down hosts, unchanged
- anything on a private subnet
Outbound only — and it never executes a command string received from the cloud.
How the agent connects →SDK Mode
TodayThe full push lifecycle for handler jobs — leases, heartbeats, cancellation.
app.use(createWeevMiddleware()); app.listen(4100);
What it puts in reach
- HTTP handlers and queue workers
- Sidekiq, Celery, BullMQ
- dbt models and warehouse loads
One middleware, then nothing else moves. Kubernetes, VMs, your language, your queue.
Start in the quickstart →Link Mode
UpcomingEndpoints you already have become governed jobs — one weev.yaml, no SDK.
jobs:
recon-batch:
http: { path: /jobs/recon }
after: [ledger-close]What it puts in reach
- existing HTTP endpoints, zero code changes
- the cron line that just calls a URL
- anything a POST can start
HTTP jobs are for invocable work; SDK jobs for long-running lifecycle.
The declaration model →03 · One control plane
Whichever surface the work runs on
Weev decides
whether tonight is the night
And
which upstreams must clear first
And
what the run is recorded as
One control plane, unchanged by where the work happens. It never executes your code and never sees your datasets — only the graph, the schedule and the record of the run.
04 · The payoff
What you delete
Nothing about the job changed. What went away is everything built around it to compensate for the schedule being implicit.
One agent.
Every job.
Observe in an hour, escalate per job. The incumbent keeps firing until Weev owns the run — that's the cutover.