# The maintenance queue is a CapEx problem: what idle servers cost while they wait (Problem Scope 5/5)

> Servers in the maintenance queue keep depreciating while they wait. Worked arithmetic for a 1,000-server fleet, and the share of the queue a digital fix clears.

- URL: https://blog.asama.ai/blog/issue-05-asama-the-maintenance-queue-is-a-capex-problem/
- Author: Manish Gautam
- Published: 2025-12-02
- Tags: Fleet problems

The maintenance queue is the set of servers pulled from service while they wait for investigation, a part or a fix. They keep depreciating the whole time. In Asama's fleet observations, 7 to 15% of a fleet sits in that queue at any given point, which makes the queue a capital cost as much as an operational one.

Infrastructure reliability is usually framed as an operational problem. Downtime costs revenue. Incidents cost engineer time. These costs are real, and they are the ones that appear in post-mortems and board reports.

But there is a larger, quieter cost that almost never appears in those reports: the capital cost of hardware sitting in the maintenance queue.

| Metric | Impact |
|---|---|
| **7 to 15%** | Fleet in maintenance queue at any given point: deployed capital, sitting idle |
| **40%** | Queued machines at Flipkart that needed only a digital fix, with no physical intervention |
| **40 to 60%** | Senior engineering time lost to debugging and firefighting |

The 7 to 15% and 40 to 60% ranges are from Asama fleet observations, and the 40% is from Flipkart's fleet.

> The maintenance queue is not an operational metric. It is a capital efficiency metric. Most finance teams have never been shown the number.

## Why the queue stays full

Hardware enters the maintenance queue for many reasons: failed components, firmware issues, configuration problems. What determines how long it stays there is the speed of [detection, investigation and remediation](https://blog.asama.ai/blog/article-01-asama-your-team-is-trapped-in-a-loop).

When detection is slow, hardware sits in an ambiguous state while engineers investigate. When investigation requires manual correlation across data sources, incidents that could be closed in hours extend to days. When remediation requires [writing a new script](https://blog.asama.ai/blog/issue-04-asama-your-automation-has-an-expiry-date) or waiting for a vendor, days extend to weeks.

At Flipkart, managing a fleet of tens of thousands of servers, Asama's technical founders found that roughly 40% of machines in the maintenance queue had problems resolvable entirely by digital means: firmware fixes, configuration corrections, kernel parameter adjustments. These did not need physical intervention. They needed [automated remediation workflows](https://blog.asama.ai/blog/article-03-asama-what-happens-when-the-loop-ends) that could execute safely and immediately.

## What the queue costs: the arithmetic for 1,000 servers

Take a fleet of 1,000 servers, with these assumptions:

- Each server cost $15,000 and is depreciated straight-line over five years: $3,000 a year, or $750 a quarter.
- 10% of the fleet is in the maintenance queue, inside the 7 to 15% range.
- 40% of queued machines need only a digital fix, as at Flipkart.

| | Servers | Depreciation per quarter |
|---|---|---|
| In the maintenance queue | 100 | $75,000 |
| Of those, digital fixes only | 40 | $30,000 |

That is depreciation on servers doing no work, before power, rack space and support contracts, and it doesn't pause: under [IAS 16](https://www.ifrs.org/issued-standards/list-of-standards/ias-16-property-plant-and-equipment/), straight-line depreciation continues while an asset sits idle. For 8-GPU servers at an assumed $250,000 each, on the same five-year schedule, the queue carries $1.25 million a quarter of depreciation, and its digital-fix share $500,000.

The same arithmetic shows how far the queue can fall. Clear the digital-fix share quickly and a queue of 7 to 15% of the fleet falls to about 4 to 9%. That is arithmetic on these assumptions, not a measured result.

## The compounding effect

Because infrastructure teams know that some percentage of their fleet will always be unavailable, they over-provision, building redundancy and buffer capacity to absorb the losses. That over-provisioning gets baked into capacity planning assumptions and persists long after the underlying problems have been addressed.

>### From Asama
>
>Asama's remediation-first approach is designed to target the maintenance queue directly, starting with the issues that need only a digital fix. Clear those and the capital that was sitting idle becomes productive again. The over-provisioning buffer can be dialled back at the next planning cycle.

## Food for thought

What percentage of your fleet is currently in the maintenance queue, and has anyone calculated what that percentage costs in idle capital per quarter?

**Update, October 2026.** Asama's fleet visibility is generally available, and detection built on it has been validated; investigation and remediation are expanding. To see what sits in your own queue, book a live comparison against your stack at [asama.ai](https://www.asama.ai), or write to contactus@asama.ai.