The event that was switched off

Date: 2026-11-11. Context: the check before a deployment is published (journal ch. 75 and 76).

What happenedCopy Anchor Link

e2e.yml runs when Vercel sends the repository an event, vercel.deployment.ready. The plan for chapter 75 said the first run would come with the deployment that followed the workflow's merge. Two merges later (#34, #35) there were two deployments, and the only run was one the assistant had started by hand.

The assistant looked for the reason in Vercel's list of events. ready is described there as the event of a deployment that "has not been promoted to production". Nothing was holding these deployments, so there was nothing to announce: the event would come once a Deployment Check made a deployment wait. It fitted everything seen so far. The guide said "there may be nothing to send", the journal added "not proven", and the user was told the probable cause and the next step: add the checks, then push.

The user added the four checks and pushed an empty commit.

The gate did what a gate should: with a check that could not report, the site kept the old version. But the release would have hung for the check's 5,000 seconds, its state running, and nothing saying that the run it waited for could never begin.

What we learnedCopy Anchor Link

• An absence was explained before it was looked at. The explanation came from reading what the event is for. The cause was a setting, and reading the project's settings is one request. The first probe to make when nothing arrives is whether the sender is on.
• "Not proven" did not stop anybody. The hedge was honest and the user acted on the probable cause all the same, because the next step was written as if it were the test. A guess that sets somebody else's next step should say how to rule it out first.
• The hedge named the wrong doubt. The journal weighed two cases, an event never sent and one sent under another name. That the sender was off was not on the list.
• A check that waits for something that cannot start looks like a slow check. Its state is running either way.

What it means for VektosCopy Anchor Link

It belongs with the four times that "nothing reported" was read as "nothing wrong" (06, 16, 19, 29). Here nothing arrived, and it was read as "nothing was due". The fix has the same shape: before a silence is explained, check that the thing which should have spoken was able to.

For the context an agent works from, it is a point about plans. A step that depends on how another system behaves is a claim until it is seen, and a plan should say which of its steps were seen. This one had three that were not: the snippet for fetch (ch. 75), "the first run follows the merge", and "the event comes once a check holds the deployment".

Follow-upsCopy Anchor Link

• Done: the events are on for vektos-web, and guide 22 has the step, with the line that reads the switch.
• The four checks and the switch as code in infra/, so that a project cannot be set up with one and not the other.
• A deployment that fails its check, seen staying staged.