Sizing Platform Capacity Around How Often Your Team Ships

An uptime target isn't a marketing line, it's a budget: everything above that threshold has to be spent on deploys, failovers, and the outages you didn't plan for, combined for the whole year¹. Tighten that target by even one nine and the budget shrinks by roughly a factor of ten, which changes how much slack you can afford to carry in every part of the stack, not just the database.

Before you size headroom, write down the actual uptime number in your contracts or your own internal goal. A team that quietly assumes "high availability" without a written number ends up sizing capacity to whatever feels safe in the moment, which is a different number every time someone new joins the on-call rotation.

Average CPU or request volume tells you almost nothing about whether you'll fall over. What matters is the ratio between your busiest hour and your typical hour. A support tool with steady traffic all day needs a different buffer than a payroll system that spikes hard on the first of the month, or a retail integration that spikes hard the week before a holiday.

Pull the last few months of your own metrics, find the highest sustained peak, not just the highest single-minute spike, and size your baseline capacity to handle that peak comfortably. A common mistake here is sizing to the single highest spike ever recorded, which usually means paying for capacity you use once a year and never again, instead of the peak your system actually sustains on a normal bad day.

Capacity headroom isn't only about customer traffic. Rolling deploys, canary releases, and database migrations all temporarily need extra capacity, because for a window you're running both the old and new version side by side. Teams that deploy often need this built into their baseline, not treated as an exception, since deployment frequency is one of the clearest signals of whether your capacity plan matches how your team actually ships².

If you deploy multiple times a day, your headroom budget has to assume overlapping versions are the normal state. If your team ships less often, on a monthly cadence say, you can plan closer to the edge day to day, but each release becomes a bigger, riskier event that needs more headroom for that one window.

A capacity plan that only names a single CPU threshold will still get you paged, because by the time you hit it you're already reacting. Set two numbers instead: a watch threshold where someone gets a notification and looks at the trend, and an action threshold where autoscaling or a manual scale-up actually fires.

Review both numbers on a fixed schedule against real traffic, not once at launch and never again. A watch threshold set for a five-person startup's traffic is meaningless a year later at ten times the volume, and stale thresholds are one of the quieter ways a capacity plan silently stops working.

None of this needs to live in a spreadsheet that one engineer maintains and nobody else understands. Track your quarterly capacity review as a recurring task in a tool like ClickUp so it survives a team change instead of quietly lapsing when that one engineer moves to a different project.

Write the actual runbook, what to check, who gets paged, what "good" looks like, in something like Trainual so a new hire can run the review without shadowing someone first. The goal isn't process for its own sake, it's making sure the review still happens the quarter after the person who built it leaves.

A quarterly capacity review can follow these steps:

1. Turn your uptime target into the yearly downtime budget it allows, so every headroom decision starts from a stated number.
2. Measure the ratio between your busiest hour and a typical hour over the last quarter instead of relying on average load.
3. Add room for rolling deploys, canary releases, and migrations, since old and new versions run side by side for a window.
4. Set a watch threshold that prompts someone to look at the trend, and a higher action threshold that triggers a capacity change.
5. Log the review as a recurring task with a named owner so it survives a team change.