# Notifications and agent handoff

Know which delivery channels are implemented and what must run to receive them.


## In-app notifications

The account notification view exposes recorded incident activity and read state. Creating a telemetry event does not necessarily create a notification: detection groups signals into problems first.

## Delivery implemented in this checkout

| Channel | Requirement |
| --- | --- |
| Email | Configured project recipient, worker Resend credentials, and sender setup |
| Slack | Project incoming-webhook URL |
| Agent webhook | Reachable receiver and configured handoff secret |
| GitHub Action | Authorized repository integration and a receiver workflow |

The current worker sends email and Slack notifications. Telegram, SMS, and WhatsApp shown in marketing previews are **not implemented provider deliveries in this worker**. The watcher schema currently stores one email destination and one Slack webhook per project, not a multi-recipient channel list.

## Agent handoff

The worker can signal your receiver through an authenticated webhook or GitHub repository dispatch. Your runner performs the investigation using your own agent credentials. The local CLI/MCP connection does not create an always-on cloud agent by itself.

A powered-off computer cannot receive or act on a live local-agent notification. Keep an authorized receiver running if continuous delivery is required; do not assume every agent client replays messages automatically after restart.

## Repeated failures

Repeated occurrences normally update an existing incident instead of notifying once per request. Lifecycle signals such as recovery or reopening are separate events; deduplication is not a promise of one message forever for the same underlying issue.

Provider delivery can fail independently from detection. Inspect worker logs and Activity for failed handoff or retry state. Never put receiver URLs, webhook tokens, or provider secrets into public issue comments.