Webhooks

Some releases should not go live the moment they are built. Somebody has to run a migration first, or a change window has to open, or another team has to say yes.

A webhook is how cloud asks. When a release is ready, cloud calls an address you provide, and then waits — the release is not live until your side reports back.

The webhooks screen: the deploy handover address at the top, and beneath it a table of deliveries showing status, event, attempts, when it was sent and what came back.

The handover

There is one handover, and it fires once a release has been built, tested and passed its gates — and only on a stage you apply yourself, never on one that deploys automatically.

That ordering matters. By the time your systems hear about it, everything cloud can check has already passed. What is left is the part only you can decide.

Deliveries

Every handover cloud has sent, newest first, with what came back.

Status	What it means
Waiting	Sent. Your side has not answered yet, and the release is held.
Applied	Your side said go. The release proceeded.
Failed	Your side refused or could not be reached. The release did not proceed.

This is not a copy of the record — it is the record the deploy was gated on. When somebody asks why a release went out at 4pm, this table is the answer.

An empty table means nothing has been handed over yet, which is the normal state for a project that has not used a gated stage.

A handover that is Waiting is holding your release. If your system answered but cloud never heard, the release is still held — the delivery row is where that shows up, and it is the first place to look when a deploy seems stuck for no reason.

Where to go next

• Deployments — the release this gates.
• Stages — which stages you apply yourself.
• Audit — the wider record of who did what.