The Runbooks Log Anomaly Detector template proposes alerting on an error-rate spike and treating zero errors as a possible logging failure. The first may indicate a service problem; the second may describe a perfectly quiet service. An agent needs an independent sign that the log feed is alive before it can distinguish those outcomes. Otherwise a confident summary can turn missing telemetry into a false all-clear.
Use two observations, not one error count
| Errors | Independent activity or ingestion signal | Report |
|---|---|---|
| None | Fresh log events or known low traffic | No observed errors in this window; do not claim zero incidents |
| None | Requests exist but no fresh logs arrive | Possible telemetry gap; check collector and query scope |
| Elevated | Fresh logs and request/traffic context available | Investigate affected service and user-visible symptoms |
| Unknown | Log API failed or data is stale | Observation unavailable; do not classify service health |
This is a decision rubric, not a production dataset. Choose a source that can establish expected activity, such as request metrics, a collector heartbeat, or a deliberately emitted test event. If the log API has no reliable ingestion timestamp, state that limitation. Distinguish an empty query result from a failed query and include the queried time window, environment, and service in the record.
The failure-mode rehearsal
- Run a read-only query against one service and save the query window, event timestamp of the newest result, and query completion time.
- Compare the result with independent service activity in the same window. If traffic is absent too, label the result inconclusive rather than fabricating an ingestion outage.
- Simulate or use a test environment where the collector stops. The workflow should report lost visibility even if the application itself remains reachable.
- Try a service error spike with fresh logs. Include a source link or query reference and confirm that the human recipient can investigate an actionable symptom.
- Verify that a failed agent run and a failed message delivery are visible separately. A passed classification that nobody receives is not a completed alert.
Google's SRE monitoring guide asks whether a page identifies an urgent, actionable, user-visible problem and warns about noisy alerts. Prometheus likewise recommends simple, symptom-focused alerting. A change from a baseline is a lead for investigation, not automatically a page. The template's 'three times baseline' example is not a universal threshold: establish a baseline from your own service and check whether requests actually failed before setting a paging rule.
Where the agent fits
The gallery template is a prompt-level starting point with web_fetch and message listed as skills. It does not supply your logging service's API credentials, source-of-truth query, or an installed schedule. Keep collection and paging in your existing monitoring stack when you need immediate response; use a bounded OpenClaw Automation to assemble context, review anomalies, and hand a human the evidence. Record what was not observed as carefully as what was.
Inspect the Log Anomaly Detector template