Team Knowledge

The more Resolve knows about your systems, the better it debugs your issues. Investigations get faster and more accurate when Resolve knows your system’s quirks, your team’s best practices, and where to look first. This part of the series introduces the different kinds of knowledge you can give Resolve and how to add them. For the complete, step-by-step reference, follow the Knowledge Setup Guide. This page is the guided tour.

​

Multiple tiers: organization, team, and individual (via Skills)

Resolve organizes knowledge into multiple tiers:

• Organization — knowledge that applies company-wide.
• Team — knowledge specific to a single team. When both exist, team knowledge takes priority.
• Individual — package your own repeatable procedures as Skills for the tasks you perform often.

For example, an e-commerce app organization might have several teams, each with their own runbooks and dashboards, plus a shared set of org-level knowledge. You manage all of it from Teams & Knowledge.

​

The types of knowledge

Within the org or any team, you can define several kinds of knowledge. Each is covered in depth in the Knowledge Setup Guide.

​

1. Resolve.md

A short, freeform description of your system — the equivalent of the README you’d hand a new engineer. Start simple: add a few lines, then grow it as investigations reveal what’s missing. See Resolve.md in the setup guide.

​

2. Alert runbooks

Attach a runbook to any alert filter so Resolve follows your team’s exact investigation steps when that alert fires. From an alert (for example, front-end error logs above threshold), add a runbook by linking an existing document or creating a new one right inside Resolve. Runbooks are what make Auto Investigations follow your playbook — see Alert Runbooks.

​

3. Dashboard guidance

Add the dashboards your team relies on, under your org or team. When you add a dashboard, Resolve automatically summarizes it and generates pointers for how to read it. You can edit those pointers — for example, “this is a load-testing dashboard; a load test is running when this metric spikes.” Dashboards come from your connected observability tools like Datadog, Grafana, or New Relic. See Dashboard Guidance.

​

4. Docs

General documentation Resolve pulls in when relevant during an investigation or incident — post-mortems, architecture notes, general guidance. Add them under Docs for the team or org. See Docs.

​

5. Skills

Skills package repeatable, multi-step procedures Resolve can run on demand or as slash commands. They sit alongside the rest of your knowledge — see Skills.

​

Close the loop with feedback

How do you know your knowledge is actually helping? Open any investigation and use the thumbs up / thumbs down control:

• Thumbs up — note what made it helpful.
• Thumbs down — note what needs to improve.

Resolve uses this feedback to improve future investigations, and you can review all of it later. This feedback loop is the core of Part 4 — Tuning Accuracy.

​

Start with the basics, then iterate

You don’t need an exhaustive document on day one, but a small baseline makes investigations far better right away. For each team, seed a Resolve.md with:

• System architecture — what the team owns: key services, repos, and environments/clusters.
• Team dictionary — acronyms, abbreviations, and internal terminology.
• Logs & traces guidance — which indexes and filters to use, the order to apply them, and an example query or two.
• Deployment guidance — where Resolve can find deploys, feature-flag, and config changes (especially if it lacks direct CI/CD access).

From there, add investigation and attribution guidance and alert runbooks as real alerts come in — keeping new knowledge grounded in real investigations instead of one long document written up front.

---

​

What’s next

With knowledge in place, you’re ready to let Resolve work automatically — triaging and investigating alerts the moment they fire. Next: Part 4 — Auto Investigations Previous: Part 2 — Connect an Integration