The answer
An error spike is a sustained rise in the share of failed tool calls, not a single failed request. Measure it as failed calls divided by calls with a known result, per server, environment and tool. A percentage on a quiet tool is noisy, so require enough traffic before the rule can fire, and require the condition to persist.
| Condition | Example starting rule | First check |
|---|---|---|
| Elevated tool errors | More than 5% errors over 5 minutes, at least 100 calls, sustained 5 minutes | Failure class, recent release, affected users |
| Slow tool calls | p95 above 2 seconds over 5 minutes, sustained 5 minutes | Downstream dependency and traffic mix |
| Unexpected silence | No calls during a period that normally has traffic | Exporter health before declaring a usage drop |
These are starting points to tune for your workload, not default Flowlines rules. Low-volume tools may need an event-based alert instead of a percentage. The MCP monitoring guide includes a copyable Prometheus rule and downloadable alert rules with tests.
A threshold tells you that something broke. It does not tell you who was affected or what they were trying to do. In Flowlines, open the failing tool to see the users, clients and use cases behind the failures, then follow an affected session. Configure a signal for a recurring problem and route it to Slack, email or a webhook. Delivery follows analysis, so keep paging for numeric thresholds in your metrics backend.
Published