These pages describe the intended behaviour of the gateway. The open-source release and the enterprise edition are being split out; details will be updated when the first release ships.
Alerts
Rules over the same counters the console reads, delivered to your channels.
Alerts are configured in the console, one rule at a time, and evaluated against the same series that metrics expose. What you chart is what you are paged on.
A rule
Every rule has four parts:
| Part | Meaning |
|---|---|
| Condition | What is measured, and the threshold |
| Duration | How long the condition must hold before firing |
| Severity | Used for routing and for grouping in the console |
| Channels | Where the notification goes |
Useful starting rules
| Rule | Why it is worth having |
|---|---|
| Quota runway below a threshold | Projects when a key reaches its limit, based on the current rate rather than the current total |
| Error rate per target over a window | Catches a provider drifting before a customer notices |
| p99 regression against a target’s own baseline | Distinguishes “this provider got slower” from “this provider is slow” |
| Held targets | Fires when a target leaves rotation, and again when it returns |
| Fallback rate | A rising fallback rate tends to appear before an error-rate alert, which makes it an early signal that a primary is degrading |
Channels
Email, Slack and webhooks. A webhook payload is the same JSON as the log line, plus the rule that fired.
Adding a channel is a console action, so a new destination does not need a restart, and a rule can be pointed at it immediately.
What alerts will not do
They do not inspect request content. A rule can key on a model, a provider, a key or a workspace, but never on the prompt.