> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Proactive reliability optimization
> Turn indicators, error budgets, and recurring failure patterns into concrete reliability improvements — including the agent that eliminates the recurrence.
Proactive reliability optimization owns the work that happens when nothing is on fire: reading what keeps
going wrong and turning it into a specific improvement. It triages where the error budget is going
and proposes the fix for a failure that has now happened often enough to be a pattern. This page
covers the outcome the module owns, the two workflows inside it, and what it needs connected.
## What this module owns
Incident response competes on speed of resolution. This module changes the axis to elimination — the
recurring cause that is handled well every time and never removed. Nobody gets to that work, because
it is never the most urgent thing in the week, and the person who would do it is the person the
incidents already consumed.
The economics are the interesting part: the highest-return work is the work that runs when nothing
is wrong. A cause that produces a page every three weeks costs more over a quarter than the change
that would remove it, but the change never gets prioritized against a live incident. This module
puts the proposal in front of you at the moment the evidence is strongest — right after the incident
that proves it.
Good looks like a falling count of repeat causes, and each closed one traceable to a specific change
you approved.
## The workflows inside it
This module contains **2 workflows**.
### Error-budget burn triage
Reads where reliability budget is actually going and ranks it — which service, which cause, and how
much of the budget each consumed. The output is an ordered list of what to fix, rather than a
dashboard you have to interpret.
### Recurring failure → fix propose
Runs when a failure pattern repeats. It identifies the recurrence, then proposes the concrete
improvement — frequently an agent that performs the maintenance the recurrence needs, configured
with its trigger, its permitted actions, and a dry run before it is live.
After an incident resolves, a **Reliability optimization** insight appears on the incident itself
with the recommended next agent and a link straight into building it, so the proposal arrives while
the incident is still fresh.
## What it needs connected
| Requirement | Why | Where to set it up |
| --------------------------- | ----------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| Incident history | Recurrence is only visible across incidents, so the module reads what has already happened | [Incident management & troubleshooting](/modules-and-workflows/sre/incidents) |
| Observability access | So burn triage is computed from your own indicators | [Built-in integrations](/manage-your-agents/build/built-in-integrations) |
| The systems the fix touches | A proposed maintenance agent needs access to whatever it maintains, scoped to that job | [Credentials & secrets](/manage-your-agents/build/credentials-secrets) |
| A knowledge base | Holds what has already been ruled out or accepted, so the same proposal is not made every month | [Knowledge base](/manage-your-agents/build/knowledge-base) |
## Enabling it
Proactive reliability optimization appears in the AI SRE family with the two workflows it contains.
Enabling the module adds it to your sidebar.
Give it the incident history and indicators to read, then bind an agent to each step you expect
to run.
## What you see when it runs
The module lists the improvements it has proposed, each with the pattern that justifies it: how
often the failure recurred, what it cost in budget, and what specifically it proposes to change.
Where the proposal is an agent, you get its configuration to review — trigger, permitted actions,
and a dry run — before anything is live.
Nothing here changes production on its own. Every proposal is a decision you take, with the evidence
that motivated it attached.
## Next steps
Where recurring production failures and their evidence are recorded.
How to inspect the history behind a reliability proposal.
How a proposed agent gets built and deployed.
The same loop applied to the fleet itself.
## Related topics
- [Modules & workflows](/modules-and-workflows/overview.md)
- [Optimize — how it works](/manage-your-agents/optimize/how-it-works.md)
- [Fleet health](/manage-your-agents/optimize/fleet-health.md)
- [Agent spend attribution](/manage-your-agents/optimize/agent-spend-attribution.md)
- [Cloud Cost](/modules-and-workflows/cost-optimization/cloud-optimization.md)