Skip to main content

Known Error Database

The Known Error Database (KEDB) is where the tenant captures what worked for past Problems and Major Incidents. Entries are typed as Workaround or Solution so the agent can tell the difference between "this gets you running again" and "this fixes the underlying cause."

What's in the KEDB​

Each entry has:

  • A plain-language description of the issue
  • A type tag: Workaround (temporary mitigation) or Solution (permanent fix)
  • The linked Problem or MI record where it came from
  • A match count showing how many incidents the entry has helped resolve since it was created
  • The full resolution notes the agent who closed the original Problem wrote

Each KEDB entry is stored as a knowledge article with the flag Restricted to Agent = True, which means:

  • Service team agents see it
  • End users do not see it
  • The virtual agent does not use it when responding in customer chat

This is deliberate. KEDB content often references internal hostnames, account names, and operational steps that don't belong in customer-facing self-service.

Surfacing KEDB matches on Problems and MIs​

When a cluster is reported as a Problem or Major Incident, the agent searches the KEDB for entries linked to similar past patterns. Matches surface on the new record as:

"This matches Known Error PRB-0042: 'Exchange connectivity drops after patch rollout.' Suggested workaround: Restart transport service. [Apply workaround info to linked incidents] [Dismiss] Suggested solution: Apply latest security patch for transport service bus. [Request as Change] [Dismiss]"

The two buttons under each suggestion do real work:

  • Apply workaround info to linked incidents propagates the workaround text as a public note across every incident linked to the cluster, giving each requester the same temporary fix.
  • Request as Change opens a pre-filled Change Request referencing the solution, so the underlying fix can move through the change process.

Dismiss removes the suggestion from this record only and signals back to the AI that it wasn't relevant here.

Creating a KEDB entry from a resolved Problem​

When a Problem moves to Resolved, the agent surfaces a prompt:

"This Problem affected 47 incidents. Save the resolution as a Known Error?"

If the agent accepts, the prompt pre-fills a new KEDB entry from the Problem's resolution notes and asks the agent to:

  1. Pick the type (Workaround or Solution)
  2. Confirm or edit the description
  3. Review the content before publishing

The new entry goes into the KEDB tagged with the originating Problem ID and immediately becomes searchable for future cluster reports.

How a Workaround becomes a Solution​

A KEDB entry can change type during its lifecycle. A common pattern:

  1. A Problem is resolved with a temporary fix. Entry created as Workaround.
  2. Engineering ships a permanent fix through a Change. The Change references the KEDB entry.
  3. When the Change is verified, the entry is re-tagged from Workaround to Solution and updated with the permanent-fix content.

The two type tags exist precisely to make this lifecycle explicit and visible to agents who hit the same pattern again.