Alerts - Superform

SuperformOS Alerts — notification channels and vault alert routing

Alerts connect vault events to notification destinations. The shipped flow centers on notification-channel creation, listing, and vault binding. Treat alert delivery as operational plumbing: channel setup first, event history and routing second.

Notification channels

A notification channel defines where Erebor can send vault events.

Field	Description
`provider`	Channel provider or transport.
`name`	Operator-facing channel name.
`config`	Provider-specific destination config. Sensitive values should be redacted in UI.
`created_by`	Creator metadata.
`created_at` / `updated_at`	Audit timestamps.

Channel endpoints

Endpoint	Method	Description
`/api/v1/notification-channels`	GET	List channels available to the operator.
`/api/v1/notification-channels`	POST	Create a channel.
`/api/v1/vaults/{chain_id}/{vault_address}/notification-channels`	GET	List channels bound to a vault.
`/api/v1/vaults/{chain_id}/{vault_address}/notification-channels/{channel_id}`	POST	Bind a channel to a vault.
`/api/v1/vaults/{chain_id}/{vault_address}/notification-channels/{channel_id}`	DELETE	Unbind a channel.

Operator flow

Create a channel with a clear name.
Bind it to the relevant vault.
Trigger or wait for a low-risk event to confirm delivery.
Keep at least one secondary notification path for high-value vaults.

Events to monitor

Common alert categories include upkeep shortfall, PPS staleness, failed keeper runs, session-key readiness, emergency pause/unpause, emergency liquidity exit arm/stop, merkle publish failures, and repeated OMS execution failures.

Troubleshooting

Symptom	Check
Channel exists but receives nothing	Confirm it is bound to the vault.
Sensitive destination appears in UI	Redact config display and rotate destination if leaked.
Alerts are noisy	Tune event thresholds before muting the channel.
Incident alert missing	Check audit logs and notification-channel binding first.

⌘I