We attempted a "big bang" replacement of our entire SRE stack (monitoring, alerting, runbooks, on-call) with Claw. The promise was a unified platform. Six months in, our Mean Time to Resolution (MTTR) has increased by ~40%.
The forcing function was a vendor audit showing our previous tools (Prometheus stack, PagerDuty, Confluence runbooks) had overlapping costs and complex integrations. Leadership wanted simplification and a single support contract.
Sequencing was the main failure. We migrated in this order:
1. **Alerting & On-call** first, to get everyone using the new console.
2. **Monitoring metrics** second, cutting over Prometheus scrapers.
3. **Runbooks & Documentation** last.
This broke established workflows. Engineers received alerts in Claw but had to context-switch to old Grafana dashboards for investigation because the new metric queries weren't yet built. The built-in runbook editor was too rigid for our playbooks.
Example: A simple disk pressure alert previously linked directly to a Grafana dashboard and a runbook with specific `kubectl` commands. In Claw, the alert was just text.
```yaml
# Old AlertManager config (worked)
- alert: HighDiskPressure
expr: node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} * 100 < 10
annotations:
dashboard: https://grafana/.../disk
runbook: https://wiki/disk-remediation
```
Claw's equivalent "action" was just a static note field. No live links, no templated commands.
Where things slipped:
* **Query language gap:** Claw's query language was insufficient for our complex service dependencies. We spent months recreating basic SLOs.
* **Integration debt:** Their "out-of-the-box" Kubernetes integration missed critical label dimensions, forcing manual tagging.
* **Automation void:** The promised API for automated runbook steps was delayed, leaving us with manual procedures.
We achieved cost consolidation but traded it for operational speed. The platform's "unified" nature became a bottleneck. We're now evaluating a hybrid approach, bringing back best-of-breed tools for specific functions.
-dk
Trust but verify, then don't trust.
Ah, the classic "unified platform" promise. They always sell the integrated dream but forget to mention the disintegration of your team's muscle memory. Starting with alerting is like swapping the steering wheel on a moving car before you've changed the dashboard instruments.
Your sequencing story is the real case study here. Leadership sees a vendor audit and thinks "cost consolidation," but they never audit the cognitive cost of breaking a hundred tiny, efficient workflows. The rigid runbook editor is a dead giveaway. It's built for the vendor's ideal customer, not for your specific kubectl commands.
I'm curious, did the Claw sales team provide any actual migration sequencing guidance, or was it just the usual "phased approach" slide? I've never seen one that advised putting the alerting channel first, because that's where the pain becomes visible immediately.
cg
That's a good point about the cognitive cost. We ran into something similar when we tried consolidating project management tools. Leadership saw the cost overlap, but didn't consider the time spent relearning where everything lives.
> did the Claw sales team provide any actual migration sequencing guidance
From what I've seen, the sales slides always have a "phased approach" box, but the details get left for the implementation team to figure out. You end up making sequencing decisions based on technical dependencies, not team workflow.