Claude is genuinely useful for incident response — parsing stack traces, suggesting triage steps, drafting postmortems. The problem is it knows nothing about your stack. Every time you open a session, you're explaining your architecture from scratch. What services exist, how they connect, what's gone wrong before, and what the standard fix is.
That context lives in your head (and sometimes in a Confluence page no one reads). Stash gives you a way to get it into Claude, persistently, so you stop pasting the same architecture diagram in every incident session.
Most of this never makes it into documentation because documentation is work. With Stash, you can add notes in natural language as you work. Claude builds up a picture of your system over time.
| Collection | What goes in it | When Claude uses it |
|---|---|---|
| services | Service name, function, owner team, key dependencies, SLA | Incident triage, architecture questions, dependency mapping |
| runbooks | Incident type + step-by-step procedure + last-used date | "What's the runbook for X?" during an incident |
| incidents | Date, service, symptoms, root cause, fix, duration | Postmortems, pattern detection, "have we seen this before?" |
| infra | Cloud config notes, regions, key env vars, cost notes | Capacity planning, cost analysis, new service provisioning |
| context | Stack summary, team structure, on-call rotation, key principles | Loaded at the start of every session via context() |
Here's what an incident session looks like once your runbooks are in Stash:
You didn't explain the architecture. You didn't look up the runbook. Claude already knows your March incident pattern and applied it to the current symptoms. That's the difference between Claude-as-generic-assistant and Claude-as-your-ops-partner.
The "second time this quarter" catch comes from your incident history in Stash. A generic LLM can't tell you that. Your Stash-backed Claude can, because you logged the last incident.
The best time to write a runbook is immediately after you've just used it. Stash makes this low-friction:
One minute to capture. Available in every future session. This is how institutional knowledge accumulates without a documentation sprint.
Most architectural documentation doesn't exist because "we'll write it later" never happens. Stash is the alternative: add a service entry when you build it, update it when something changes. Not a wiki sprint — a running log.
Two minutes per service. Claude now knows your notification service exists, what it does, and who owns it. When something breaks and involves email delivery, Claude can suggest checking SES delivery logs without you explaining that you use SES.
| Not Stash | Use instead |
|---|---|
| Live metrics, logs, or traces | Grafana, Datadog, CloudWatch — Stash doesn't have live data access |
| Secrets management | AWS Secrets Manager, Vault — never store secrets in Stash |
| Ticketing and incident management | PagerDuty, Jira — Stash doesn't integrate with these |
| Config-as-code or infrastructure state | Terraform, Pulumi — Stash is notes, not a source of truth |
If you're calling Claude via API (common in DevOps automation scripts), token costs add up. Stash uses FTS5 keyword search — it returns only the matching records, not your entire knowledge base. A search across 500 runbook entries returns roughly 192 tokens of results on average, versus thousands of tokens if you embedded the full context. For automation use cases, this matters.
Stash is a remote MCP server — no install, no local setup. You add one URL to Claude Settings and you're done. Signups are free, self-serve, and use Google OAuth.
Sign in at stashlite.com and add your connector URL to Claude Settings under Integrations. Takes two minutes.
Free tier: 2,500 records · 50 queries/month. Pro: 100k records · 1k queries — £8/month.
No install. No app. Paste one URL and every conversation knows your stack.
Pricing may change as the service develops. Cancel anytime.