Notifications
Circuit Breaker can route in-app notification sinks for alerting on events.
Notifications
Notification sinks let you define where alerts should go and how they are grouped.
Typical workflow:
- Open Notifications (admin navigation), or Settings → Integrations → Notifications.
- Create sink destinations.
- Add routes to control which severities each sink receives.
- Test and validate delivery.
Sink types
Each sink has a Name, a Provider Type, and one destination field.
| Provider Type | Required field | What the destination receives |
|---|---|---|
| Slack | Webhook URL | A JSON POST of the form {"text": "…"} |
| Discord | Webhook URL | A JSON POST of the form {"content": "…"} |
| Microsoft Teams | Webhook URL | A JSON POST of a MessageCard ("@type": "MessageCard") |
| Recipient Email | An email sent through your configured SMTP settings |
Email sinks
An email sink holds the recipient address and nothing else. The server, port, credentials, TLS mode, and sender address all come from Settings → SMTP — the same configuration used for invites — so there is no per-sink SMTP setup and no per-sink credential to manage.
This means an email sink cannot deliver until SMTP is configured. The sink form says so when it is not, and both Test and real delivery return “SMTP is not configured” rather than a connection error.
Webhook URL storage
An incoming-webhook URL is a credential: anyone holding it can post into that channel. Circuit Breaker encrypts webhook URLs with the vault key before storing them, and the sinks list shows only a masked preview — enough to tell two destinations apart, never enough to use one.
When editing a sink, leave the masked value as it is to keep the current URL; replace it outright to point the sink somewhere new. Rotating the vault key (Settings → Security) re-encrypts stored webhook URLs along with every other secret.
Routes
Routes connect a sink to a minimum severity — a floor, not an exact match. A route set to
warning receives warning and critical alerts; critical receives critical only; info receives
everything on the ladder; * receives every event regardless. A sink with no route receives nothing.
An alert whose severity is not one of info / warning / critical is treated as critical, so it
reaches every route rather than being dropped.
Troubleshooting
- Verify the destination URL (or recipient address) on the sink.
- Confirm a route exists whose minimum severity is at or below the one you expect, and that both sink and route are enabled.
- Use the sink’s Test action and read the result panel it returns — this is the only delivery diagnostic; there is no delivery log or history view.
What a Test actually establishes
Test sends down the same path as a real alert and classifies the provider’s response the same way, so the two agree. What it proves is bounded, and the result panel is worded to match:
| Result | What it means | What it does not mean |
|---|---|---|
| Accepted by provider | The provider returned a 2xx and took the request | That a person saw it. The provider can still drop, filter, or delay the message downstream |
| … did not accept it (terminal) | The request was refused and will not be retried — bad credentials, a rejected URL, missing configuration | That the destination is unreachable in general; fix the named cause and test again |
| … did not accept it (retrying) | A transient failure — rate limit, timeout, provider outage. Bounded retries apply | That it will eventually succeed |
The panel reports the attempt count, the HTTP status, and any Retry-After window the provider
asked for. A rejected response is never reported as success: acceptance, configuration being saved,
and a human reading the message are three separate events.
The result also names which destination answered. The provider name alone cannot tell two Slack destinations apart, and an outcome you cannot attribute is not one you can act on.
Where the outcome has a known next action, the panel states it — re-enter credentials that could not be decrypted, wait out a rate-limit window, complete a half-configured destination. An outcome the UI does not recognise is reported with the server’s own reason and no invented advice.
- For Email sinks, check Settings → SMTP, since the sink sends through it.
- If a sink starts failing right after a vault key change, re-save its webhook URL — the stored ciphertext can no longer be decrypted with the current key.
- If behind a proxy, ensure outbound network access to target endpoints.