Event types

This is the canonical table of every event type managed.dev emits to customers. The same catalog drives three channels: webhooks (subscribe by exact type, category:<name>, or "*"), the in-app notification bell, and email. Each type carries a default severity and per-channel flags — failures, security events, and critical alerts interrupt; routine successes stay quiet.

The machine-readable version is GET /v1/webhook-endpoints/event-types (or mf webhooks event-types) — build subscription lists from it rather than hard-coding this table.

the event types

Sorted by category, then type. in-app means the event rings the dashboard bell (the notifications page shows every event regardless); email means it sends a message, subject to the per-category preferences at GET/PUT /v1/notification-preferences.

Category	Event type	Severity	In-app	Email	Fires when
backup	snapshot.completed	info	—	—	A backup job finishes; the payload carries the new snapshot_id.
backup	snapshot.restored	info	yes	yes	A snapshot restore completes.
build	build.completed	info	—	—	A build produces a signed, content-addressed artifact.
build	build.failed	error	yes	yes	A build fails before producing an artifact.
deploy	deploy.completed	info	yes	—	A deployment finishes and the environment serves the new release.
deploy	deploy.failed	error	yes	yes	A deployment can’t complete; the environment stays on its prior release.
env	env.created	info	yes	—	A new environment is provisioned.
env	env.create_failed	error	yes	yes	Environment provisioning fails.
env	env.destroyed	info	—	—	An environment is destroyed.
env	env.refreshed	info	—	—	An environment is re-seeded from production.
env	env.reset	info	—	—	An environment is reset.
job	job.succeeded	info	—	—	Any async job reaches succeeded.
job	job.failed	error	yes	yes	Any async job reaches failed.
observability	observability.alert	warning¹	yes	yes	A site health rule transitions into alerting.
observability	observability.resolved	info	yes	—	An alerting rule recovers.
security	malware.detected	critical	yes	yes	A scan finds and quarantines malicious files.
security	malware.scanned	info	—	—	A malware scan completes.
security	security.key_created	warning	yes	yes	An API key is created.
security	security.key_revoked	warning	yes	yes	An API key is revoked.
security	security.member_role_changed	warning	yes	yes	A team member’s role changes.
security	security.member_removed	warning	yes	yes	A member is removed from a team.
security	security.team_deleted	warning	yes	yes	A team is deleted.
security	vulnerability.matched	critical¹	yes	yes	A known CVE newly matches an installed plugin or theme.
site	site.created	info	—	—	A site is created.
site	site.deleted	warning	yes	yes	A site is deleted.
site	site.transferred	warning	yes	—	Site ownership moves to another team or account.
team	team.member_added	info	—	—	A member joins a team.
team	team.invite_created	info	—	—	A team invite is created.

¹ Severity is set per event from the underlying finding — observability.alert can be warning or critical, and vulnerability.matched reflects the worst new match.

Operator-only types

A few types — host.offline, host.recovered, and malware.quarantine_failed — have an operator audience: they route to the platform ops channel only and are never delivered to customer webhooks, the bell, or customer email. They don’t appear in the subscribable catalog.

Note

job.succeeded and job.failed fire for every job type, so they’re the catch-all if you’d rather react to a generic job lifecycle than each specific event. Higher-level types like deploy.completed fire for the same terminal jobs — subscribe to whichever granularity fits your handler.

envelope shape

Every delivery wraps the payload in a common envelope. The type field is what you switch on; data holds the type-specific payload — see event types & payloads for examples.

a deploy.completed delivery

{
  "id": "evt_01J9F2KQ...",
  "type": "deploy.completed",
  "site_id": "site_01J7ABCD...",
  "env_id": "env_01J8C4RX...",
  "created_at": "2026-06-23T18:04:11.412Z",
  "data": {
    "job_id": "job_01J9F2KQ...",
    "job_type": "deployment.deploy"
  }
}

The HTTP request also carries the Forge-Signature header — verify it before trusting the body — and a Forge-Delivery-Id header that stays stable across redeliveries, which is what you dedupe on. Delivery history and replay live at GET /v1/webhook-endpoints/{id}/deliveries.

putting events to work

A few events anchor common automations:

• malware.detected kicks off an incident response — pull the detections, review the quarantine, and restore from a snapshot if needed.
• deploy.failed pages your team or posts to chat the moment a release doesn’t roll, instead of waiting for someone to notice.
• security.key_created and the other security.* audit events feed a SIEM or compliance trail without polling the audit log.
• observability.alert wires site health straight into your on-call rotation.

next steps

Webhook eventsThe catalog with payload examples and the subscription selectors.

Webhooks overviewCreating endpoints, retries, and delivery history.

SignaturesVerifying the Forge-Signature header before trusting a payload.

Async jobsThe jobs behind job.succeeded and job.failed.