Events are part of the product

A deployment should leave evidence

A deployment request is only the beginning. Customers need to know what was planned, what ran, what failed, what was verified, and what state exists now.

Those transitions are useful outside the dashboard, so the platform treats them as events instead of making every external system reconstruct them by polling.

A webhook is a signal, not a database

A signed webhook tells a receiver that something changed. The receiver verifies the signature, records the event, and decides whether it needs more detail from the API.

The API remains the source for current resource state. This makes missed events recoverable and makes duplicate delivery safe to handle.

Use events to connect systems

Events can start a release gate, update a ticket, refresh an internal inventory, notify an operator, or ask another service to reconcile its view.

The receiving system owns its response. Tasmanian Cloud does not need to know how a customer organises tickets, incident work, or internal approvals.

Security belongs in the delivery path

Webhook signing keys should be references, not values copied into every deployment. Kleis can hold the key material while the delivery worker uses a scoped capability.

Receivers should verify the signature, check the event identity, record a delivery id, and make processing idempotent.

Patch reports are events too

A patch scan is more useful when a customer can act on its result. A finding can become a signed event with the host, package state, severity, scan time, and remediation state.

That event can feed a webhook, an email report, or an ntfy-compatible operational notification without changing the health state of the workload itself.

Polling still has a place

Polling is useful for reconciliation and for recovering a consumer that was offline. It should not be the only way to learn that a run finished or a patch report changed.