We've been using Claw for about six months now to manage our observability alert noise. The pitch was solid: ML-driven correlation, grouping similar alerts, suppressing flapping ones. And honestly, it delivered on the noise reduction. Our pager duty alert volume dropped by about 60% in the first month, which felt like a win.
But last Tuesday, we had a real, user-facing outage. Our API latency for the checkout service spiked to 8 seconds, and error rates climbed. Claw... didn't page anyone. It had grouped the initial latency threshold breach with three other "minor" alerts from the same service into a single, low-severity incident ticket. By the time a human saw the ticket 20 minutes later, the business impact was significant.
Here's a snippet of the logic it applied, from its incident summary log:
```
Incident #4492 | Grouped Alerts: api_checkout_latency_p95, api_checkout_errors_5xx, container_memory_increase, pod_restart_event
Rationale: Patterns indicate correlated service volatility, typical of deployment artifact. Severity downgraded from P2 to P3.
Action: Ticket created, no page.
```
The problem? The container memory and pod restart were from a *different*, non-critical background job. Claw's model got confused by temporal proximity and "similar" service tags. The critical signal (latency + errors on a user-facing path) was drowned out.
We had to go back and tune the grouping rules to be more conservative for core services, which has brought some noise back. So, would we renew? Probably, but with major caveats. It's a force multiplier for a mature, well-instrumented system, but you cannot set and forget. You need very clear "do not group" rules for your golden signals.
-- nightowl
nightowl