When the same incident keeps resurfacing and your team spends time re-diagnosing a problem they’ve already solved, you have a process gap — and a known error database (KEDB) is designed to close it. A KEDB is a central repository that captures diagnosed errors, their root causes, and available workarounds so that support teams can resolve recurring incidents faster and more consistently. This guide explains exactly what a KEDB is, how it fits into ITIL problem management, and how to implement one that delivers real value.
What Is a Known Error Database (KEDB)?
A known error is a problem that has a documented root cause and a workaround, even if a permanent fix hasn’t been deployed yet. The known error database is where those records live. It’s a structured library that your service desk can query when an incident comes in, checking whether the underlying problem has already been identified and whether a temporary resolution exists.
The KEDB sits within the problem management process, but it’s actively used by incident management teams. When an agent receives a ticket, they should be able to search the KEDB before starting from scratch. If a match exists, they apply the documented workaround and resolve the incident in minutes rather than hours. That’s the core value proposition.
In ITIL 4 terms, a known error is a specific record type within the service management system. It’s distinct from a problem record (which may still be under investigation) because a known error has a confirmed root cause and at least one documented workaround, even if a permanent fix is pending.
How a KEDB Fits Into ITIL Problem Management
Problem management in ITIL has three phases: problem identification, problem control, and error control. The KEDB is the primary output of error control. Here’s how those phases connect:
- Problem identification: Recurring incidents or major incidents trigger a problem record. The team begins root cause analysis.
- Problem control: The team investigates the root cause, documents findings, and identifies workarounds. Once root cause is confirmed, the problem becomes a known error.
- Error control: The known error is logged in the KEDB with its root cause, workaround, and status. It stays there until a permanent fix is implemented and verified.
The KEDB isn’t a dead archive. It’s a live reference tool. Problem managers should review it regularly to prioritize which known errors get permanent fixes, based on how frequently they trigger incidents and what the business impact is.
What a Known Error Record Should Contain
A KEDB is only useful if each record contains enough detail for someone who wasn’t involved in the original investigation to act on it quickly. At a minimum, each known error record should include:
- Unique identifier: A reference number that links the known error to its parent problem record and any related incidents.
- Error description: A clear, plain-language description of what the error looks like from the user’s perspective and from the technical side.
- Root cause: A concise explanation of the underlying technical cause. Avoid vague language — “database timeout caused by misconfigured connection pool” is more useful than “database issue.”
- Symptoms: Specific indicators that help agents recognize when this known error is the likely cause of a new incident.
- Workaround: Step-by-step instructions for temporarily restoring service. If no workaround exists, that should be documented explicitly.
- Permanent fix status: Whether a change is in progress, planned, or not yet scheduled — and a link to the relevant change record if applicable.
- Affected services and CIs: Which configuration items or services are involved, so agents can filter by affected area.
- Date identified and last reviewed: Timestamps that help teams know whether the record is current.
- Owner: The problem manager or team responsible for driving the permanent fix.
Why a KEDB Reduces Incident Volume and Resolution Time
The operational benefits of a well-maintained KEDB are measurable. Here’s how each benefit plays out in practice:
Faster Incident Resolution
When an agent can find a known error record in under a minute and follow a documented workaround, mean time to restore (MTTR) drops significantly. Instead of escalating to Tier 2 or opening a new investigation, the agent applies the workaround and closes the ticket. Teams that consistently use the KEDB during incident triage report shorter handling times for recurring issues.
Consistent Support Quality
Without a KEDB, resolution quality depends on which agent picks up the ticket and whether they’ve seen this issue before. With a KEDB, the workaround is standardized. Every agent follows the same steps, which eliminates variability and reduces the risk of well-intentioned but incorrect fixes that make things worse.
Fewer Repeat Escalations
A recurring incident that hasn’t been connected to its root cause gets escalated repeatedly, consuming Tier 2 and Tier 3 resources. The KEDB cuts that escalation chain by giving frontline agents the information they need to handle the incident themselves, reserving escalation for genuinely new problems.
Better Prioritization for Problem Management
When the KEDB is linked to incident records, problem managers can see exactly how many incidents each known error is generating over time. That data supports rational prioritization: known errors causing fifty incidents per month get permanent fixes before those causing two. Without the KEDB, these decisions rely on gut feel or whoever shouts loudest.
Reduced User-Facing Impact
Users experience fewer delays when agents have clear workarounds available. Even if the underlying problem isn’t fixed yet, users can get back to work faster — which reduces frustration and, for external-facing services, protects customer satisfaction scores.
Handling Known Errors Without Workarounds
Not every known error has a workaround. In some cases, the root cause is identified but there’s no viable temporary fix — for example, a hardware defect that requires a replacement part, or a vendor bug that requires a patch. These records still belong in the KEDB.
When no workaround exists, the record should document that explicitly, explain why no workaround is available, and provide agents with guidance on what to communicate to users. That might include an estimated resolution timeline if a change is in progress, or escalation instructions for high-priority cases. The absence of a workaround doesn’t make a record useless — it prevents agents from wasting time searching for a solution that doesn’t exist yet.
Implementing a KEDB: Practical Steps
Building a KEDB from scratch can feel overwhelming, especially if your problem management process is immature. The following approach keeps it practical and avoids over-engineering.
Start With Your Most Frequent Incidents
Pull a report of your top recurring incidents over the past 90 days. Any incident category appearing more than five or ten times is a candidate for a known error record. This gives you a backlog of high-value records to create immediately, rather than trying to build a comprehensive database before you’ve established the habit.
Choose Where the KEDB Will Live
Your KEDB needs a home that’s searchable and accessible to your service desk team during incident handling. Options include:
- A dedicated KEDB module within your ITSM platform (most enterprise tools include this)
- A structured knowledge base article type, if your ITSM tool doesn’t have a separate KEDB module
- A shared database or wiki as a temporary solution while you evaluate ITSM tools
The best option is integration within your ITSM platform. When known error records are linked to problem records, incident records, and change records, agents can navigate between them without switching tools. InvGate Service Management, for example, handles problem management natively and allows teams to link problem records to related incidents and changes within the same platform, which supports a connected KEDB workflow without additional tooling.
Define a Consistent Record Format
Standardize the fields every known error record must contain (see the list above). Use templates in your ITSM tool to enforce completeness. A record missing its root cause or workaround steps isn’t useful to an agent under pressure.
Establish a Review Cadence
Stale records are a real problem. A workaround that was valid eighteen months ago may no longer apply after a system upgrade. Assign ownership to each record and schedule periodic reviews — quarterly is a reasonable starting point for most organizations. Records linked to known errors where a permanent fix has been deployed should be marked resolved and removed from active search results.
Integrate the KEDB Into Incident Triage
The KEDB only works if agents actually use it. Build a KEDB search step into your incident triage procedure. Some ITSM platforms can surface likely known error matches automatically based on incident category, affected CI, or keywords in the description — reducing the friction of manual searching. Make it a standard step, not an optional one.
Measure Usage and Impact
Track how often agents reference KEDB records when resolving incidents. Track the volume of incidents linked to each known error over time. Monitor whether incidents linked to a known error resolve faster than incidents that aren’t. These metrics tell you whether the KEDB is actually being used and whether it’s delivering the expected reduction in resolution time.
KEDB and the Knowledge Base: Understanding the Difference
The KEDB is sometimes confused with the knowledge base. They serve related but distinct purposes. A knowledge base is a broader collection of articles covering how-tos, FAQs, system documentation, and general reference material — much of it aimed at end users as well as agents. A KEDB is specifically for diagnosed errors with confirmed root causes and workarounds, and it’s primarily a tool for problem and incident management teams.
In practice, some organizations integrate KEDB records into the knowledge base as a specific article type. That’s a valid approach as long as the records are clearly tagged and searchable as KEDB entries. The key is that agents can distinguish between a general troubleshooting guide and a confirmed known error with a documented root cause.
KEDB in Cloud and Distributed Environments
Cloud infrastructure introduces complexity that can make known error management harder. Components change frequently, services are updated continuously, and many dependencies are managed by third-party providers. Despite this, the KEDB remains relevant — in some ways more so, because the pace of change increases the likelihood that the same failure mode will appear repeatedly before a vendor deploys a fix.
In cloud and remote work environments, the KEDB should include vendor reference information where relevant. If a known error is tied to a third-party cloud service, the record should document the vendor’s case number or status page URL, so agents can check whether the vendor has deployed a fix. This prevents your team from continuing to apply workarounds after the underlying issue has been resolved upstream.
Frequently Asked Questions
What is the difference between a problem and a known error in ITIL?
A problem is an unresolved cause of one or more incidents. It may still be under investigation. A known error is a problem where the root cause has been identified and at least one workaround has been documented. In ITIL terms, a problem becomes a known error when root cause analysis is complete, even if a permanent fix has not yet been implemented.
Is a KEDB the same as a knowledge base?
No, though they overlap. A knowledge base is a broad collection of reference material for end users and agents. A KEDB is specifically a repository of confirmed known errors with root causes and workarounds. Some organizations store KEDB records within the knowledge base as a specific record type, but the two serve different purposes and have different audiences.
Who is responsible for maintaining the KEDB?
The problem management team owns the KEDB. Problem managers create and update known error records as root causes are confirmed. However, incident management teams are the primary consumers — they reference the KEDB during triage. The best results come from close collaboration between the two: incident managers flag patterns that should be investigated, problem managers document findings and feed them back into the KEDB.
What happens to a known error record when a permanent fix is deployed?
Once a permanent fix is implemented and verified, the known error record should be updated to reflect that the fix is in place and the error is resolved. It should be retired from active search results so agents don’t apply outdated workarounds. The record should be retained for historical reference — linked to the problem record and the change record that delivered the fix — but marked clearly as closed.
Does every ITSM tool include a KEDB?
Most enterprise ITSM platforms include problem management functionality that supports a KEDB, but implementation quality varies. Some tools have a dedicated KEDB module with structured fields, links to related records, and search integration during incident handling. Others treat the KEDB as a knowledge base category, which requires more manual discipline to maintain. When evaluating ITSM tools, check specifically how the platform handles known error records, how agents access them during incident triage, and whether records can be linked to problems, incidents, and changes.
Pricing accurate as of the publish date and subject to change. Verify current pricing on each vendor’s official site before purchasing.
Photo by Vitaly Gariev on Unsplash
