Costing AI agent downtime requires three terms: direct cost — the value the agent would have produced had it been available; cascading cost — downstream work blocked, delayed, or degraded because the agent wasn't there; and recovery cost — the labor spent detecting, diagnosing, and restoring the agent to service. The formula, built from your own measured inputs, gives you a defensible number to weigh against the cost of the redundancy or monitoring investment you're considering.

Why This Number Is Worth Building Before an Incident

Teams often only attempt to cost downtime after a significant incident, as part of a post-mortem or a budget request for better redundancy. That timing works against the number's credibility — a downtime cost calculated after the fact, sized suspiciously close to whatever budget is being requested, looks reverse-engineered even when it isn't.

Building the costing formula in advance, as a planning exercise independent of any specific incident, produces a number that can be trusted and reused. It also forces a useful conversation before anything breaks: what would it actually cost us if this agent were unavailable for an hour, a day? That conversation surfaces gaps — an agent embedded deep in a critical workflow with no fallback, a dependency nobody had mapped — well before an outage forces the discovery.

The Three Cost Terms

Direct Cost

This is the value the agent would have produced during the outage window, had it been running normally. For an agent handling a measurable volume of tasks, this can be approximated as: (task volume the agent would normally process in the outage window) × (value per task, using whatever outcome value measure you already track for that agent). See Measuring the ROI of AI Agents for how to establish a per-task value figure — cost per outcome or deflection rate — that this term depends on.

Direct cost is not simply the agent's fully-loaded operating cost during the outage window, since the agent isn't consuming resources while down. It's the value it would have delivered, which is usually a larger and more consequential number.

Cascading Cost

This term captures the cost that ripples beyond the agent's own task queue. If the agent's output feeds a downstream process — another agent, a human team, a customer-facing workflow — its absence can block or degrade that downstream work even after the agent itself is restored, because a backlog accumulated during the outage takes time to clear.

Cascading cost is highly dependent on the agent's position in the broader workflow topology. An agent that's a dead-end (its output isn't consumed by anything else time-sensitive) has minimal cascading cost. An agent sitting upstream of several other automated or human processes can have cascading cost that dwarfs its direct cost. Mapping this dependency structure before an incident — not discovering it during one — is itself valuable independent of the costing exercise. See Cascading Failures in Multi-Agent Systems for how failure propagates through agent dependency chains, and Dead Letter Queues: Failed Agent Job Recovery for how a backlog that accumulates during an outage gets cleared afterward, which is itself a cost worth including in this term.

Recovery Cost

This is the labor cost of detecting the outage, diagnosing the cause, and restoring service — the on-call engineer's time, any escalation involved, and the time spent on a post-incident review. Model this as: (hours spent across everyone involved in detection, diagnosis, and remediation) × (their fully loaded hourly cost). Detection time specifically deserves its own scrutiny — an outage that takes an hour to detect because there's no health check or alerting in place costs more in this term than one caught within a minute by automated monitoring, independent of how long the actual remediation takes. See Health Probes and Readiness for AI Infrastructure for how detection time is typically reduced, and Service Level Objectives for AI Services for how to define the availability target this term should be measured against.

Downtime Cost Is Rarely Linear with Duration

A common mistake is assuming cost scales linearly with outage duration — that a two-hour outage costs roughly twice a one-hour outage. In practice, the relationship depends heavily on when the outage occurs relative to demand patterns and on whether a backlog compounds.

An outage during a low-traffic window may cost far less per hour than the same outage during peak demand, simply because direct cost scales with the task volume that would otherwise have been processed. Conversely, an outage that causes a queue to back up can produce cascading cost that grows faster than linearly with duration, if the backlog itself starts causing secondary effects — SLA breaches with customers, human teams falling behind on the volume the agent normally absorbs. Build the model to reflect this rather than assuming a flat per-hour rate; at minimum, separate your estimate for a peak-demand outage from a low-demand one.

Silent Degradation Belongs in the Same Framework

A hard outage — the agent stops responding entirely — is the easiest failure mode to cost, because detection is usually fast and the boundary of the outage window is clear. A harder and often more expensive failure mode is silent degradation: the agent stays available and appears to be functioning, but produces lower-quality, incorrect, or incomplete output.

Silent degradation typically goes undetected longer than a hard outage, because there's no clear signal (an error rate, a health check failure) triggering an alert. The direct cost term for this failure mode should reflect the gap between the value the agent would have produced at normal quality and the value it actually produced at degraded quality — which requires an ongoing quality or eval signal to detect in the first place. See Agent Evaluations: Scoring Quality and Regressions for the monitoring that makes this detectable, and Post-Incident Forensics for AI Agents for reconstructing the actual duration and impact of a degradation event after it's found — which is often longer than initially assumed, precisely because it wasn't caught by binary uptime monitoring.

A Worked Illustrative Example

The following is illustrative only, using made-up inputs, to show the formula's shape — do not use any figure below as a benchmark.

Suppose an agent normally processes N tasks per hour, each worth an estimated value V (from your own outcome measure). An outage lasting H hours during a demand period with a demand multiplier M (relative to baseline) produces:

Direct cost ≈ N × M × H × V

Suppose the outage also causes a backlog that takes an additional B hours to clear, during which downstream capacity is constrained, at an estimated cascading cost rate of C per hour:

Cascading cost ≈ B × C

Suppose the incident required R person-hours to detect and remediate at a blended loaded rate of L:

Recovery cost ≈ R × L

Total cost of the incident ≈ (N × M × H × V) + (B × C) + (R × L)

The value of writing it this way is that each variable is independently improvable: reducing detection time reduces R, reducing backlog-clearing time reduces B, and improving redundancy reduces H directly. The formula tells you which investment moves the number most for your specific workflow topology — not a generic industry answer.

Using the Number

The output of this exercise is a comparison figure — weigh it against the cost of the redundancy, failover, or monitoring investment being considered, using the same formula-based cost accounting discipline described in FinOps for AI Agents: Controlling Token and Tool Costs for costing that investment side. It's an internal planning input, not a number to publish or use in a vendor conversation, since the specific values depend on internal workflow details that are commercially sensitive.

Common Questions

How do we estimate the demand multiplier or backlog duration if we've never had a significant outage?

Use your existing traffic and queue data even without a full outage history — most systems already show demand variation across time of day or day of week, and queue depth after a partial disruption (a slow deploy, a brief upstream dependency issue) gives you a real data point for backlog-clearing behavior, even if it never became a full outage.

Should this costing exercise include reputational or customer-trust impact?

Only if you can tie it to something measurable — a contractual SLA credit, a documented churn event, a support cost spike. An unquantified "reputational damage" term invites the same credibility problem as reverse-engineering a number after an incident: it's whatever size makes the argument work. If you can't measure it, name it as a qualitative risk alongside the quantified formula rather than folding an invented number into the total.

How often should this model be rerun?

Whenever the agent's role in the workflow changes materially — new downstream dependents added, a change in task volume or value per task — or after an actual incident, when you have real data to replace an estimated variable with a measured one.

What Good Looks Like

  • The downtime cost formula is built before an incident, as a planning exercise, not reverse-engineered after one to justify a budget ask.
  • Direct, cascading, and recovery cost are modeled as separate terms with their own variables.
  • The model accounts for non-linearity — outage cost varies by timing and by whether a backlog compounds.
  • Silent degradation is costed using the same framework as a hard outage, with quality monitoring as the detection mechanism.
  • The resulting number is used internally to size availability investment, not published as an external claim.