Lead-Time Awareness
Back to Performance Tuning and Capacity Planning · Trend-Based Projections · Per-Resource Runway · Scenario Modeling · Service Offerings
Factoring in how long it actually takes to provision more of each resource, so the warning arrives with enough runway to act. A forecast produces the date capacity runs out. That is not the date anything has to happen, and treating it as one is how a planned expansion becomes an emergency.
1. The Longest Runway Can Need the Earliest Decision
This is the point of the illustration above, and it is the one that catches people. Four resources, similar runways — and the physical server with eleven months of headroom needs deciding before the cloud instance with nine, because one takes ten weeks to arrive and the other takes a minute.
Ranking by runway therefore produces the wrong order of attention. The order that matters is runway minus lead time, and nothing else.
2. Lead Time Is More Than Procurement
The clock starts when someone decides and stops when the capacity is carrying traffic. Almost everything in between gets left out of the estimate:
- Deciding. Agreeing there is a problem, choosing the option, finding the budget. Frequently the longest step and never in anyone's figure.
- Approval and purchase, which for anything capital is measured in weeks.
- Delivery, which for hardware has not been reliably short.
- Installation and commissioning, including the window it needs.
- Migration. New capacity rarely helps until something moves onto it, and moving a large dataset is itself constrained — see data gravity.
- Verification, because capacity nobody has tested is not capacity.
Estimate each step from what the last one actually took rather than from what it should take. The record exists in tickets and purchase orders.
3. Cloud Has Lead Times Too
“Elastic” removes the delivery step and not the others, and several cloud lead times are long enough to matter:
| Change | Realistic lead time |
|---|---|
| More instances of something already running | Minutes |
| A quota or limit increase | Hours to days, and it can be refused |
| Larger instance type in a constrained region | Days, if the capacity is available at all |
| Resizing a managed database | A maintenance window, and often a failover |
| Reserved capacity or a committed-spend change | Weeks, and a commercial conversation |
| Re-architecting to scale horizontally | Months, which is the one that is never on the list |
The quota is the sharpest of these. It costs nothing, takes a day, and is discovered at the moment scaling was supposed to save you. Raising the limits you are nowhere near is cheap insurance.
4. Capacity Arrives in Lumps
Demand grows smoothly and supply does not. You cannot buy ten per cent of a server, half a database tier or a fifth of a licence. Each step is a decision with a cost and a lead time, which has two consequences.
- There is a right moment, and it is before the last one. Adding capacity while the system still works is a project; adding it afterwards is an incident with the same cost and worse options.
- Bundle the steps. If two resources need expanding within a few months of each other, one coordinated change beats two, and seeing that needs all the forecasts together.
5. The Decision Date Is the Deliverable
A forecast that produces “storage runs out in September” will be acknowledged and deferred. One that produces “decide by 15 June, because procurement is six weeks and migration is three” is a diary entry, and diary entries survive budget meetings.
- State the decision date, not the exhaustion date.
- Give it an owner.
- Show the arithmetic, so that if someone disputes it they are disputing a lead time rather than the conclusion.
- Recalculate on the review cadence, since lead times change — usually upwards.
How We Approach It
- Measure each lead time from history: how long the last comparable change actually took, start to finish, including deciding.
- Include every step — approval, delivery, installation, migration, verification — rather than only procurement.
- Check the cloud limits you are not near, and raise the ones that would be a surprise.
- Subtract from each runway and re-rank by what is left, which usually changes the order.
- Produce decision dates with owners, and the arithmetic beside each.
- Revisit on the review cadence, because lead times drift.
What You Get
- A measured lead time per resource, taken from what previous changes took rather than from an estimate.
- Decision dates rather than exhaustion dates, each with an owner and the arithmetic behind it.
- Priorities re-ranked by runway minus lead time, which is frequently a different order.
- The quota and limit increases that cost nothing now and would cost an outage later.
- Opportunities to bundle expansions that fall close together.
The sentence this work produces is the useful one: not “we run out in September” but “this is decided by June, and here is why”.