Cloudflare OS: the failure record

Tail Workers

A Tail Worker is a Worker assigned to another Worker, invoked with that Worker's execution log after each request: the exceptions thrown, the logs written, the outcome, the timings.

tail_consumers = [{ service = "loop-failure-intake" }]

export default {
  async tail(events, env) {
    for (const e of events) {
      if (e.outcome === 'ok' && !e.exceptions.length) continue;
      await env.DB.prepare(
        'INSERT INTO tasks (state, title, failure_class, layer, source) VALUES (?,?,?,?,?)'
      ).bind('open', e.exceptions[0]?.name ?? e.outcome, ..., 'tail').run();
    }
  }
};

That is the missing link, and it is small. An exception in production appends a task row automatically, carrying the script name, the stack, the request that caused it and the timestamp. The rule stops depending on attention.

Two design notes for doing it properly here rather than naively:

Deduplicate on failure class, not on occurrence. A broken route throwing five hundred times should produce one task with a count, not five hundred tasks. The dedup key is the exception name plus the script plus the normalised route.

A Tail Worker cannot tail itself. Whatever handles the intake needs its own error path, and the honest one is a dead-letter queue rather than a second tail.

Verdict: install. This is the highest-priority item in the entire series — not because it is the most impressive, but because it makes an existing law mechanical instead of aspirational.

Logpush and Log Explorer

Logpush pushes logs in near real time to storage or a SIEM. Log Explorer keeps them queryable in the dashboard.

The current position is that a production failure is diagnosed by re-running the thing that failed. That works for deterministic bugs and fails completely for the interesting ones — the intermittent transport fault, the payload that truncates only above a size threshold, the request that succeeded from one caller and 403'd from another. Those are diagnosed by reading what actually happened, and there is no record to read.

This build has already lost time to precisely that class. A dispatch payload containing a pipe character truncated silently and looked like an intermittent Apps Script fault for long enough to be misdiagnosed as one. With request logs, the pattern — every truncated payload contains a |, no exceptions — is visible in one query.

Pointing Logpush at the existing R2 bucket costs nothing and gives every future investigation a record to work from. With the Iceberg catalog from Part 2 on the same bucket, those logs become queryable with the same SQL as everything else.

Verdict: install. Cheap, and it converts "reproduce it" into "look it up".

Workers Builds and gradual deployments

Deploys here go through scripts/ship.mjs, which is a real gate — it checks that HEAD matches origin, that the tree is committed, that the deploy runs from the repository root, and it fails on a list of accumulated invariants. That gate is load-bearing and should not be replaced.

What is missing is on either side of it.

Workers Builds runs the build on Cloudflare from a git push, so the deployed artifact is traceable to a commit on the account rather than to whatever was in a working directory. This complements the ship gate rather than replacing it: the gate decides whether a deploy is allowed, Builds records what was deployed.

Gradual deployments put a new version in front of a percentage of traffic before all of it. For a site with one origin and an agent population that ships several times a day, a bad render reaching ten percent of requests instead of all of them is a meaningful difference.

Version metadata is the small companion piece: a binding that lets a response name the version that served it. When something is wrong on the live site, the first question is always which deploy did this, and today that is answered by correlating timestamps.

Verdict: version metadata and gradual deployments — install. Workers Builds — later, and only alongside the existing gate, never instead of it.

What this part does not recommend

Do not move deploy authority to a git push. The ship gate exists because deploys from the wrong directory produced a Functions-less build and a production outage, and because concurrent agents overwrote each other's shipped work. A push-to-deploy pipeline that bypasses those checks would reintroduce both failure classes with better ergonomics. Builds is welcome as a recorder. It is not welcome as the decider.

Verdicts

Next: Part 8 — reaching private things.