What is a Known Error Database (KEDB) and why does it matter?
A known error database (KEDB) is one of those things every ITSM framework mentions and almost nobody maintains well. The concept is simple: keep a record of problems you have identified, the underlying cause you have found (or at least narrowed down), and whatever workaround exists while a permanent fix is pending. Simple enough on paper. In practice most KEDBs are either empty, out of date, or buried in a wiki that nobody opens when a ticket arrives.
This post explains what a KEDB actually is, how it differs from a plain knowledge base and from problem management records, why it tends to die without deliberate maintenance, and how it can grow as a side effect of the work your team already does.
What a KEDB is, precisely
A known error is a problem for which the root cause has been confirmed (or at least a reasonable working hypothesis is documented) and a workaround exists. The KEDB is the structured store of those known errors.
Three things distinguish a KEDB entry from a generic knowledge article:
- It is tied to a problem, not just a symptom. A knowledge article might say "if VPN disconnects, reconnect and clear your DNS cache." A KEDB entry says "this VPN issue traces to a race condition in the client when the wireless adapter switches access points. Permanent fix is in the vendor's next release. Workaround: disable the automatic AP roaming setting."
- It has a known-error status. It is a documented, accepted state of the environment: we know this is broken, we know why (or approximately why), and we know what to do until it is fixed.
- It is linked to problem management. When a change or a patch closes the root cause, the known error record should be closed or archived too.
How it differs from a general knowledge base
A general knowledge base is broader. It contains how-to articles, procedures, FAQs, troubleshooting guides, and documentation. Most of it describes expected system behavior. A KEDB describes confirmed abnormal behavior.
In practice the distinction matters for two reasons:
First, routing. When a new ticket arrives about a known symptom, you want to surface the KEDB entry fast, not make the agent search through general articles hoping something matches. A KEDB query on symptom keywords should return a workaround the agent can use immediately, without reading the full problem history.
Second, accuracy. A knowledge article that says "restart the service" is fine for general guidance. But if the real answer is "this has a confirmed root cause and a workaround, and the fix ships next Tuesday," an agent needs to know that, not just the generic troubleshooting step. The KEDB entry carries that precision because it was written by someone who investigated the problem.
The two are complementary. A healthy service desk uses a knowledge base for general guidance and a KEDB for confirmed known states. More on how the broader knowledge layer works is in IT knowledge management with AI.
Where problem management fits in
Problem management is the ITIL process that turns repeated or impactful incidents into a formal investigation, finds root causes, and drives permanent fixes. The KEDB is the output of that investigation: once problem management confirms a root cause (or a working hypothesis with a workaround), it creates a known error record.
The relationship is: problem management feeds the KEDB. When problem management closes a problem (root cause fixed), it closes or archives the corresponding KEDB entry. When a new incident matches a KEDB entry, first-line support can apply the workaround immediately without escalating, and incident management has documentation to link to.
What goes wrong in most organizations is that this connection is never established. Problem management runs in one tool or spreadsheet, the KEDB is a second spreadsheet or a separate wiki, and front-line agents know about neither. So when the same known problem generates its eighth incident, the agent treats it as a fresh ticket. The KEDB sat there with the answer and nobody used it.
For a deeper look at how AI changes the investigation side of this process, see problem management with AI.
Why KEDBs die
Maintaining a KEDB manually requires someone to:
- Write the entry when a known error is confirmed
- Keep the workaround current as the environment changes
- Close or update entries when permanent fixes ship
- Tag entries with enough searchable terms that agents can find them from symptom descriptions on incoming tickets
The second problem is discovery. Even a well-maintained KEDB does nobody any good if the agent handling the ticket does not know to look there, or if the search interface requires perfect keyword matching. A ticket that says "Teams keeps dropping people mid-call" will not surface a KEDB entry titled "VoIP degradation on VLAN 20 after switch firmware update" unless someone connects those terms.
The third problem is authorship. Whoever writes KEDB entries needs enough technical context to document the root cause and the workaround accurately. That is often problem management or a senior engineer, not the analyst closing the ticket. So there is always a handoff required, and handoffs are where information gets lost.
The flywheel model: KEDB that grows from resolved tickets
A better model treats every resolved ticket as a KEDB candidate rather than a one-time event. When a ticket is resolved, you have two pieces of information: the symptom (from the ticket) and the resolution (from the agent). If that resolution matches or extends an existing KEDB entry, the entry can be enriched. If no entry matches, the resolution is a candidate for a new one.
This is the core idea behind Knowledge-Centered Service (KCS), which is explored in KCS: knowledge-centered service explained. The difference from traditional KCS is where the curation work happens: instead of asking agents to write articles during or after every ticket, you let the ticket resolution generate a candidate and have a lighter-weight curation step confirm it.
When an AI agent handles a ticket and applies a workaround from the KEDB, it has all the information needed to note whether the workaround worked. When a human agent resolves a ticket, the resolution note is a structured data point. Neither requires a separate "write a knowledge article" step.
The flywheel outcome: the KEDB grows as a side effect of resolving tickets, not as a separate project. Entries stay current because they are updated when workarounds succeed or fail. Stale entries are flagged when the linked workaround stops producing resolutions.
This only works if the underlying ticket data is clean enough to extract signal from. A resolution note that says "fixed" or "done" is not a KEDB candidate. A note that says "cleared cached credentials via Group Policy reset, ticket closed" is. Ticket quality is a prerequisite, not an afterthought.
How AI agents interact with a KEDB
An AI agent that reads a new ticket can query the KEDB in the same step as querying the broader knowledge base. The agent compares the symptom description against existing known errors, ranks matches by relevance, and includes the top match in its response or internal note to the team.
When the match confidence is high, the agent can include the workaround directly in a reply to the end user or as a structured note for the handling team. When confidence is lower, it surfaces the candidate match for a human to review before acting.
The second interaction is on ticket close. When an agent or a human closes a ticket with a resolution note, an enrichment pass can check whether the resolution matches an existing KEDB entry or represents new information worth capturing. This is the "build" step in the flywheel: closed tickets accumulate into a richer known error database without anyone scheduling a knowledge project.
This kind of agentic knowledge loop is different from a traditional knowledge management system. There is no import step, no article-writing workshop, no quarterly review meeting. The database is a living record of what the team actually did, not what someone thought was worth documenting in advance. See our overview of AI service desk automation for more on how agents handle structured knowledge retrieval. For details on how ITSM Autopilot integrates with your ITSM platform to make this work, see the documentation.
What a KEDB entry should contain
A minimal KEDB entry needs:
- Symptom description: what the user reports, in terms close to how tickets arrive
- Affected scope: which systems, services, or user groups are affected
- Root cause or working hypothesis: what is actually wrong, even if it is "vendor issue, cause not yet confirmed"
- Workaround: the concrete steps that resolve or mitigate the symptom for the user
- Status: known error open, under investigation, fix planned, fix in progress
- Fix reference: if a change or patch is planned, a link or reference to it
- Owner: who in problem management owns this record
- Last verified date: when the workaround was last confirmed to work
Common mistakes with KEDBs
Mixing known errors and general knowledge in the same bucket. When everything lives in one flat knowledge base, agents cannot filter for "things we know are broken right now." The KEDB should be queryable separately, even if it sits in the same system.
Writing KEDB entries in technical language only. The symptom description needs to match how end users describe the problem, not how the infrastructure team diagnosed it. An entry that perfectly describes a VLAN misconfiguration is useless if it never surfaces when an agent searches "Teams audio drops."
Not closing old entries. A KEDB with twenty open entries, some of which were fixed two years ago, trains everyone to ignore the database. Closed entries should be marked clearly and excluded from active queries, but kept for historical reference.
Treating the KEDB as a secret internal document. Workarounds that are safe for end users to apply themselves should be in the self-service knowledge base too. The KEDB does not need to be end-user-facing, but the workaround information from it can be.
Frequently asked questions
What is the difference between a known error and a problem?
A problem is an investigation: something is causing repeated incidents and you are working to understand why. A known error is the result of that investigation: the cause is confirmed (or hypothesized) and a workaround exists. Every known error was previously a problem. Not every problem becomes a known error immediately.
Does a KEDB replace a knowledge base?
No. A knowledge base covers expected system behavior, how-tos, and general troubleshooting. A KEDB covers confirmed abnormal states with documented workarounds. Both serve agents. They work best when they are queryable together but distinguishable by type.
How often should KEDB entries be reviewed?
At minimum, review entries whenever a related change or patch ships. In practice, any entry with a "last verified" date older than three months and no recent linked tickets should be reviewed for accuracy or closure. The flywheel model reduces this burden because entries are updated as part of ticket resolution, not in a separate review cycle.
Can an AI agent create KEDB entries automatically?
An AI agent can generate draft entries based on resolved ticket data. Those drafts need a human review step before they become authoritative records, because the agent does not have full visibility into whether the resolution was a true workaround or a one-off fix. Shadow mode, where the agent proposes entries for human confirmation, is a practical starting point.
What happens to KEDB entries when the problem is permanently fixed?
They should be closed, not deleted. A closed entry preserves the investigation history and the count of tickets resolved with the workaround. That information is useful for post-incident reviews and for understanding the historical impact of a problem.
Real service by real people. Administrative work by machines. A KEDB that grows on its own is what that looks like in the knowledge layer.