Alerts
Notifications when Guard finds a problem.
Alerts notify your team, by email or Slack, when Guard finds something that needs attention, so a person hears about it before a customer does. Today alerts are sent for anomalies.
Alerts inform, they do not stop anything
In beta, an alert tells a person and the person decides. Nothing is paused automatically. An admin can pause the agent with the Pause button on its card or page (see Rules and circuit breaker).
Set up channels
An admin sets the channels in the dashboard under Settings → Alert channels. Alerts go only to the channels set here, and each organisation has its own.
- Email. Add one or more recipient addresses.
- Slack. Create an incoming webhook in your Slack workspace and paste it in. It is stored securely and never shown again, so use Replace or Remove to change it. Alerts work with any Slack incoming webhook. The Approve and Reject buttons on approval requests work only through the Slack connection Impraint sets up for you in beta (see Approvals).
Click Send test next to a channel to check it delivers without waiting for an incident. A test message is labelled TEST and never affects real anomalies. Each channel can be tested once every 30 seconds. Click Save changes when you are done.
A channel is used only when it is configured. If nothing is configured, no alert is sent, and an anomaly that happened before you set up a channel is not sent afterwards.
Who is told
Every alert goes to your configured email recipients and Slack channel, whatever the severity: medium, high or critical.
Approval requests use the same channels, but differently: Guard tries Slack first, and emails your recipients only when Slack is not set up or keeps failing. See Approvals.
What you receive
Slack and email carry the same content in plain language:
- A one-sentence summary, such as "the agent called the same function many times in a short window"
- Severity, agent, metric, the current value against the normal value, and when it was detected (in UTC)
- Evidence, such as the function name and call count for a loop, or the failed trace IDs for an error spike
- A link to the incident on the dashboard
One alert per incident
- You get at most one alert per agent and metric every 30 minutes.
- If the severity goes up, for example from
mediumtohigh, you are alerted again. - If a channel fails to deliver (for example Slack is briefly down), Guard retries only that channel, after 30 seconds, 2 minutes and 5 minutes. Channels that already delivered are not sent a duplicate.
When the incident ends
When someone resolves an anomaly, marks it a false positive, or Guard closes it itself (silence closes when traces resume), Guard sends a short follow-up to the channels that delivered the original alert:
- RESOLVED: the incident was closed, and how long it was open.
- FALSE ALARM: it was marked a false alarm, so no action is needed.
What you can do about an alert
| Action | Who | Effect |
|---|---|---|
| Acknowledge | Any role | Marks that a person saw the alert |
| Resolve | Analyst or admin | Closes the incident and sends the RESOLVED notice |
| False positive | Analyst or admin | Closes it as not real and sends the FALSE ALARM notice |
| Pause agent | Admin | Guard blocks every call from the agent until it is resumed |
For a loop or climbing cost, pause the agent with the Pause button on its card or page, fix the cause, then resume it.
Known limits in beta
- There is no pause link in the alert message. Open the agent in the dashboard to pause it.
- A new agent only gets loop alerts at first. Spike alerts (tokens, cost, latency, error rate) start after its first nightly baseline, about the second day. Silence alerts need about a week of history.
- PagerDuty is not available in beta.
- Times in messages are UTC.
- There is no mute or quiet-hours setting.
- Content-safety alerts are kept in their own history, not in this list.