How to Build an Infrastructure Headroom Worksheet Before You Need One

Track, per service: current peak utilization (CPU, memory, connection pool, or whatever the actual bottleneck is), the trailing 90-day growth rate, the hard ceiling (instance type limit, database connection cap, queue depth where latency falls apart), the lead time to add capacity, and the date you cross most of the ceiling at the current growth rate, say four-fifths of it. That last column is the one that turns a spreadsheet into an early-warning system.

Don't track every service. Track the ones with a real ceiling: your primary database, your job queue, your cache layer, anything with a hard connection or IOPS limit. A stateless API server behind autoscaling doesn't need a row; it needs a max instance count that's high enough to be a non-issue.

Each service row on the worksheet needs these five fields:

• Current peak utilization, measured on whatever resource is the real bottleneck, such as CPU, memory, or a connection pool.
• The trailing three-month growth rate, so the sheet reflects how fast the service is actually filling up.
• The hard ceiling: an instance type limit, a database connection cap, or the queue depth where latency falls apart.
• The lead time to add capacity, using the slowest realistic path rather than the fastest one.
• The date you cross about four-fifths of the ceiling at the current growth rate, which is the early-warning column.

The lead time column is where most worksheets lie. If provisioning a bigger database instance takes fifteen minutes but re-sharding a table that's outgrown its instance class takes three weeks of migration work, the lead time for that service is three weeks, not fifteen minutes. Write down the slowest realistic path, including approvals, vendor lead time on reserved capacity, and the time to test the change in staging.

Once lead time is honest, the warning date writes itself: it's the date you hit the ceiling, minus the lead time, minus a buffer you're comfortable defending to your CEO if you're wrong. A team that ships a warning date without that buffer is really just moving the outage a few weeks later and calling it planning.

The common leak isn't underprovisioning, it's overprovisioning that nobody revisits. A service gets sized for a launch spike, the spike passes, and the instance count never comes back down because nobody owns that decision. Put an owner's name next to every row. Say a service has been running under a third of its capacity for two full growth cycles: that's a resize ticket, not a monitoring dashboard entry.

The other leak is reserved capacity bought for a growth curve that didn't happen. Reserved instances and committed-use discounts are worth it only when your 90-day growth rate is stable enough to trust a one-year commitment. If a service's growth rate swings by more than half between quarters, keep it on-demand until the curve settles. Locking in a discount on a number you don't trust turns a pricing decision into a bet you didn't mean to make.

A fifteen-minute review at the start of each sprint, covering only rows whose warning date moved closer, keeps this from turning into a chore nobody does. Assign the review to whoever's on call that week; they already have the freshest picture of what's tight. Anything that crosses the threshold in the next two lead-time windows becomes a ticket, not a conversation.

When a row's warning date keeps slipping closer every sprint, that's a signal the growth-rate estimate is wrong, not that you need a bigger buffer. Recompute the trailing rate on real numbers instead of adding padding on top of a stale one.

If a service ever crosses its hard ceiling before the worksheet flagged it, the fix isn't a bigger safety margin bolted onto the existing process. Find the specific step that failed: was the growth rate stale, was the lead time underestimated, or did nobody own the row. Fixing that specific step keeps the worksheet trustworthy; padding every number with extra margin just delays the next miss and makes the sheet harder to read.

Keep a short log of near-misses next to the worksheet itself. A pattern of misses in the same column, across different services, usually points at one bad assumption baked into how that column gets filled in, and that's worth fixing once rather than patching service by service.