Soroban testnet ledger reading… ledger close 5.000000 s ± 0.000050 · measured, not assumed read-only · these pages never sign or submit

Engine runs · a scheduled job, not a daemon

What the engine did, and what its scheduler delivers

There is no daemon, no uptime, no CPU telemetry: ADR-001 made the engine a cron-scheduled job. Its runs are visible as workflow runs in the repository. What follows is what the record actually supports — including the part that flatters nobody.

The scheduler delivers about 7.5% of its declared cadence

Declared: every 15 minutes. Measured on 2026-09-14, on two independent workflows with different creation dates and different windows — which is what makes this a property of the platform rather than of one file. These are that day's figures, frozen with their record; the delivery rate has moved between measurements before, and pnpm measure:cadence re-measures it.

WorkflowWindowExpected ActualDeliveredGap min / median / max
engine-cron.yml2,487 min166 137.8% 102 / 136 / 294 min
scheduler-smoke.yml10,218 min681 507.3% 109 / 212 / 331 min

About 7.5% of declared slots, and a worst observed gap of 331 minutes — 5.5 hours. GitHub does not guarantee scheduled workflows; it delays or drops them under load, and low-activity repositories are throttled hardest. Documented platform behaviour, not a misconfiguration — but the workflow file says every 15 minutes and reality is roughly every two hours. Source: docs/evidence/2026-09-14-scheduler-cadence/.

This is survivable because the action threshold is a full day of warning — 17,280 ledgers at five seconds each. Even the worst observed gap fires at least four times inside a 24-hour window, seven to ten at the median. The margin comes from the threshold, not from the scheduler.

Last run: see the workflow runs in the repository — a static page cannot know it. No countdown is shown anywhere here, because there is no honest number for one.

What it decided

Decide-only runs read the watched entries, resolve one target per key, refuse expired candidates and protected subjects, and record skips with reasons. The correction history is committed: docs/evidence/2026-09-12-engine-decision-correction/ (targets, expiry refusal, shared-payer agreement) and docs/evidence/2026-09-13-engine-thresholds/ (warning tier visible without becoming action).

What it actually extended

One unattended extension is on the record: guinea-pig A's instance on 14 September, decided and submitted from a local timer at ledger 4,670,261, fee charged 44,725 stroops — with the threshold deliberately raised to 1,500,000 so it would act. As far as the record goes, the production cron has never extended anything; no row on this site claims otherwise. Every extension, whoever triggered it, is on the extension history.

What it refused

Guinea-pigs B and C sit outside the watched config until their crossings, and the write guard refuses them — and the shared code entry — by default, naming the date an override would spend. If the engine saw them early it would dutifully bump them and destroy weeks of ageing with no error anywhere. The refusal is the feature.