Why a 99% busy system is not slightly worse than a 75% busy one

A young woman cooks alone behind the counter of a small lantern-lit noodle bar while a long queue of people with umbrellas waits along a rain-soaked street outside, bicycles at the kerb and a cat asleep on a stool.

Raising utilisation from 75% to 99% is a third more load. It is thirty-three times the queue.

00.250.50.75105101520ρ=0.5 → 1ρ=0.75 → 3ρ=0.9 → 9ρ=0.95 → 19L = ρ / (1 − ρ)ρ=0.99 → 99OFF THIS CHART
The queue is not long because the load is high. It is long because the headroom is small.

Open the M/M/1 Queue Simulator at its defaults. Work arrives three times an hour, the server handles four an hour, and the readout says utilisation 0.750 with 3.000 items in the system and 2.250 of them waiting.

Twenty-five percent spare capacity, and a queue of three. That already sounds worse than it ought to.

Those four numbers also demonstrate the one result in queueing theory worth memorising. Arrivals are 3 per hour, the average wait in the system is 1.000 hours, and the average number in the system is 3.000. That is Little's law, L = λW, and its remarkable feature is that it assumes nothing at all about the distributions. Change the arrival pattern, change the service times, add servers, and it still holds for any queue that is stable. Almost everything else below depends on the modelling assumptions; this does not.

One formula, and where the trouble lives

For this queue the average number in the system is L = ρ / (1 − ρ), where ρ, spoken "rho", is utilisation. The tool's default puts 0.75 into that and gets exactly the 3.000 on screen.

The numerator is the load. The denominator is the headroom, and it is the denominator that decides everything. As ρ approaches 1, the headroom approaches zero, and dividing by a number approaching zero does what it always does.

  • ρ = 0.50 → L = 1
  • ρ = 0.75 → L = 3
  • ρ = 0.90 → L = 9
  • ρ = 0.95 → L = 19
  • ρ = 0.99 → L = 99

Read that column as a manager would. Going from half loaded to 99% loaded is not twice the work, it is 1.98 times the work, and it is ninety-nine times the queue. The last four percentage points, from 95 to 99, cost more queue than the entire journey from 0 to 95.

Why the failure has no warning stage

This shape explains a pattern anyone who has run a service will recognise. Utilisation drifts up over months and nothing happens. Response times are fine at 60%, fine at 70%, a little worse at 85%. Then one week the system is unusable, and the load that week is barely different from the load the week before.

There was no cliff in the load. The cliff is in the formula, and a queue is a poor early warning system for its own collapse because the damage is concentrated in the last few percent.

It also explains why the fix is so often "add one more server" rather than "make the server faster". Adding capacity moves ρ down the curve, and the leverage of moving from 0.95 to 0.90 is enormous precisely because that is where the curve is steep.

The preset with no answer

The tool ships three presets, and the third one is the interesting one. Light load runs at ρ = 0.4. Heavy load runs at 3.8 against 4.0, so ρ = 0.95 and L = 19, matching the table above.

The third is labelled unstable, and it sets arrivals to 4.2 against a service rate of 4.0. That is ρ = 1.05, and there is no steady-state answer to compute. Work arrives faster than it can leave, the queue grows without limit, and the formula returns a negative number, which is mathematics telling you the question was ill-posed.

A system at ρ > 1 does not settle into a bad state. It has no state. Every hour the backlog is larger than the hour before, and nothing except reducing arrivals or adding capacity will ever change that. Watch the simulation run and the queue simply climbs off the top of the chart.

Two assumptions worth naming

M/M/1 assumes arrivals are Poisson and service times are exponential, which means both are memoryless: the chance of an arrival in the next second does not depend on how long you have waited. Real traffic is often burstier than that, and burstiness makes the queue longer, not shorter.

So the numbers above are optimistic. The real lesson survives the assumptions anyway, because it comes from the 1 − ρ in the denominator rather than from the details of the distributions. Any system with variable arrivals and finite capacity has the same wall in the same place.

Aiming for 100% utilisation is not efficiency. It is the request that the queue be infinite.

References (1)

Published 31 May 2026 · corrections welcome via the corrections page.