0% 5h quota used ·
resets in 2h
restart window open · live · 08/09/2026 12:03 CEST
Safe to restart
What is running, what fires next, and where a rebuild fits — a restart is assumed to take about 10 minutes.
Nothing holds a lock, no request is being dispatched, and the next firing is far enough out.
This gap lasts
26m
until 08/09/2026 12:30
The CLI this image is built on
npm checked 24m ago| Version | Means | |
|---|---|---|
| Running | 2.1.263 | what the container has, read at boot (24m ago). It cannot change while the container lives — the CLI is installed as root and the daemon runs as uid 1000, so the self-updater has nowhere to write. |
| npm latest | 2.1.263 | what a rebuild installs — and today it is also tagged next, ahead of stable, so it is a pre-release. |
| npm stable | 2.1.236 | the conservative tag, where the two differ. Not a free swap: 2.1.236 sends no utilisation figures, so tracking it would empty the meters on /quota. |
Up to date: the container is on the version npm publishes. A rebuild would change no CLI.
Running now
one lock per task indata/locks · clearNo lock is held — no task or script is running right now.
Firing next
the 12 soonest of 37 in 72 hours · the whole week| In | When | Task | Does | Budget | Policy | |
|---|---|---|---|---|---|---|
| in 26m | 08/09/2026 12:30 | de:wasserversorger-enrich | Enrich German water suppliers (Wasserversorger) with contact details and the published water-analysis URL, and append results to the campaign JSONL. | 90m | autonomous | |
| in 1h | 08/09/2026 13:30 | de:netzbetreiber-replies | Triage new replies from German grid operators and extract data from their answers, then send the queued follow-ups and reminders via the guarded sender. | 75m | autonomous | |
| in 5h | 08/09/2026 17:30 | de:wasserversorger-enrich | Enrich German water suppliers (Wasserversorger) with contact details and the published water-analysis URL, and append results to the campaign JSONL. | 90m | autonomous | |
| in 7h | 08/09/2026 19:30 | de:netzbetreiber-replies | Triage new replies from German grid operators and extract data from their answers, then send the queued follow-ups and reminders via the guarded sender. | 75m | autonomous | |
| in 10h | 08/09/2026 22:30 | de:wasserversorger-enrich | Enrich German water suppliers (Wasserversorger) with contact details and the published water-analysis URL, and append results to the campaign JSONL. | 90m | autonomous | |
| in 14h | 09/09/2026 02:30 | de:wasserversorger-enrich | Enrich German water suppliers (Wasserversorger) with contact details and the published water-analysis URL, and append results to the campaign JSONL. | 90m | autonomous | |
| in 17h | 09/09/2026 05:00 | _global:sentry-verify | Check whether merged sentry-triage fixes actually deployed and actually worked, and resolve in Sentry the issues whose errors stopped. The ones still bleeding are left open and come back on the triage worklist as FIX-FAILED. Deterministic, no LLM. | 15m | autonomous | |
| in 18h | 09/09/2026 06:00 | _global:sentry-triage | Weekly Sentry triage of the cms, telecom and renovation repos — fix what is safely code-fixable, one draft PR per repo, journal the rest. Ignores third-party noise. | 110m | pr | |
| in 19h | 09/09/2026 07:30 | de:wasserversorger-enrich | Enrich German water suppliers (Wasserversorger) with contact details and the published water-analysis URL, and append results to the campaign JSONL. | 90m | autonomous | |
| in 19h | 09/09/2026 07:30 | de:netzbetreiber-replies | Triage new replies from German grid operators and extract data from their answers, then send the queued follow-ups and reminders via the guarded sender. | 75m | autonomous | |
| in 20h | 09/09/2026 08:00 | _global:decisions-escalate | Announce platform decisions to Google Chat and defects to GitHub the day they are opened, and re-raise anything still unanswered. Deterministic, no LLM. Without it _global's register is write-only — which is the failure the register exists to fix, one level up. | 5m | autonomous | |
| in 20h | 09/09/2026 08:00 | tn:decisions-escalate | Announce decisions to Google Chat and defects to GitHub the day they are opened, and re-raise anything still unanswered after 30 days. Deterministic script, no LLM. | 5m | autonomous |
Where a restart fits
gaps of 10 minutes or more · a firing occupies its longest run in the last twenty, or its budget where the ledger has none| From | Until | Long enough for | Then fires | |
|---|---|---|---|---|
| now | 08/09/2026 12:30 | 26m | de:wasserversorger-enrich | you are here |
| 08/09/2026 13:59 | 08/09/2026 17:30 | 3h 31m | de:wasserversorger-enrich | |
| 08/09/2026 18:30 | 08/09/2026 19:30 | 1h 00m | de:netzbetreiber-replies | |
| 08/09/2026 19:59 | 08/09/2026 22:30 | 2h 31m | de:wasserversorger-enrich | |
| 08/09/2026 23:30 | 09/09/2026 02:30 | 3h 00m | de:wasserversorger-enrich | |
| 09/09/2026 03:30 | 09/09/2026 05:00 | 1h 30m | _global:sentry-verify | |
| 09/09/2026 05:01 | 09/09/2026 06:00 | 59m | _global:sentry-triage | |
| 09/09/2026 06:37 | 09/09/2026 07:30 | 53m | de:wasserversorger-enrich, de:netzbetreiber-replies | |
| 09/09/2026 09:02 | 09/09/2026 12:30 | 3h 28m | de:wasserversorger-enrich | |
| 09/09/2026 13:59 | 09/09/2026 17:30 | 3h 31m | de:wasserversorger-enrich |
What a restart actually costs
- A run in flight is lost, not resumed. The daemon installs no signal handler, so the agent's child process dies with it. Nothing is written to the ledger for that run, and its lock file survives — the task stays shut until a later run steals the lock (budget + 15 minutes).
- A cron missed while the container is down is not caught up. Each task gets a plain croner instance at boot, which only ever computes its next occurrence. A 06:00 job restarted through is a 06:00 job that did not happen today.
- A claimed queue request is orphaned.
data/queue/<id>.lockis written to claim a request and never removed, so a dispatch killed mid-flight is never re-claimed. It stayspendingforever with a lock beside it. - Approvals and the queue survive. Both live in files and are re-read on the next poll, so anything still undecided is picked up after boot — approvals every 5 minutes, the queue every 30 seconds.
Read in Europe/Paris, the same clock the crons are written against. This page trusts data/locks and data/queue, which the daemon writes as it goes — but it cannot see a run the daemon is about to start, and if the daemon itself is gone (it is live, last tick 2m ago) then "nothing is running" means nothing can run, not that all is well. Widen or narrow the verdict with ?grace=30 and ?hours=168.