Forecast how many months until load reaches tested capacity at your growth rate, and model series or parallel availability against your objective.
Enter a service’s current peak load, its tested capacity, and its monthly growth rate, and this tool tells you how many months of headroom you have left. That number — not utilisation percentage — is the one that belongs in a planning conversation, because 65% utilisation means something completely different at 2% monthly growth than at 15%.
The forecast sits inside a single service profile that also carries the objective, the observed availability, and the component architecture, so one set of numbers drives every model on the page instead of being retyped into four calculators. Everything runs in your browser and the formulas are stated openly, so you can check the arithmetic rather than trust it.
Load is modelled as compounding monthly, so the months remaining before load reaches capacity is:
months = ln(capacity / current load) / ln(1 + monthly growth)
Continuous compounding is the right default because traffic growth is a rate applied to a base that keeps getting bigger, not a fixed number of requests added each month. Assuming linear growth is the single most common way a capacity plan ends up optimistic.
What that formula actually implies is worth seeing laid out, because the intuition is poor:
| Current utilisation | 2%/mo | 5%/mo | 8%/mo | 15%/mo | 25%/mo |
|---|---|---|---|---|---|
| 50% | 35.0 months | 14.2 | 9.0 | 5.0 | 3.1 |
| 65% | 21.8 months | 8.8 | 5.6 | 3.1 | 1.9 |
| 80% | 11.3 months | 4.6 | 2.9 | 1.6 | 1.0 |
Two things fall out of that table. Doubling the growth rate more than halves your runway, and the drop from 50% to 80% utilisation costs about two-thirds of the time you had left, not 30% of it. A service sitting comfortably at 65% with 15% monthly growth has one quarter before it is in trouble — which is roughly the time it takes to procure, test, and roll out additional capacity. That is why the tool raises a finding at six months rather than waiting for a threshold breach.
The forecast returns no crossing when growth is zero or negative, or when current load is zero, and it is capped at 1,200 months. If load already meets or exceeds capacity it returns zero, and utilisation at or above 100% is raised as a critical finding — at that point you are not forecasting, you are describing the present.
The model is only as honest as the capacity number you feed it, and this is where capacity plans usually go wrong. The field is labelled tested capacity for a reason. Useful numbers come from a load test that ran to the point of degradation, or from an observed peak where latency stayed inside the objective. Numbers that produce a reassuring and worthless forecast include a vendor’s datasheet maximum, a theoretical calculation from instance specifications, and the highest throughput ever recorded regardless of what response times were doing at the time.
Use the same unit on both sides — requests per second, concurrent sessions, or whatever your bottleneck is actually measured in. And use peak load, not average: capacity is exhausted at the peak, and a service averaging 40% of capacity can be saturating daily.
The assumptions are stated on the page rather than buried: availability events are treated as uniformly distributed, components are modelled as independent, growth compounds monthly with no planned scaling included, and downtime cost applies the hourly figure you supplied without secondary effects. Each of those is a simplification, and each is one you should be able to see.
Capacity is one output of a profile that models several things at once from the same inputs.
Error budget. From the objective, the tool derives the monthly and annual downtime budget and the number of failed requests a 30-day month allows. At 99.9% that is 43.2 minutes a month, 8.76 hours a year, and 10,000 failed requests out of 10 million. If observed availability falls below the objective, that gap is raised as a high-severity finding.
Architecture availability. Component availabilities are combined either in series, where every component is required, or in parallel, where any one succeeding is enough. Series multiplies the availabilities together; parallel multiplies the failure probabilities and subtracts from one. Three components at 99.99%, 99.95%, and 99.9% model to 99.84006% in series — worse than the weakest link, which is the property people find counter-intuitive. The same three in parallel model to better than eleven nines. If the modelled architecture lands below the stated objective, that is flagged.
Downtime cost. Observed availability is converted to monthly downtime and multiplied by the hourly impact figure. At 99.85% observed and $25,000 per hour, that is 1.08 hours and roughly $27,000 a month — a number whose purpose is to make a reliability investment comparable to its cost, not to be precise.
Where you need to go deeper on any one of these, dedicated tools exist and a saved profile carries into them: the SLA and SLO calculator for error budgets, burn rates, and service tiers; the MTBF and MTTR calculator for incident histories and redundancy analysis; the business impact calculator for the full financial picture.
| Finding | Severity | Trigger |
|---|---|---|
| Capacity headroom is low | Critical | Utilisation at or above 100% |
| Capacity headroom is low | High | Utilisation at or above 85% |
| Observed availability misses the objective | High | Observed below stated SLO |
| Capacity threshold forecast within six months | Medium | Forecast crossing in six months or fewer |
| Modeled topology is below the objective | Medium | Series or parallel model below stated SLO |
| Error budget calculated | Info | Always, with the derived figures |
The medium-severity six-month warning is the one to act on. By the time utilisation crosses 85% and the high-severity finding appears, the lead time for adding capacity frequently exceeds the time remaining.
Inputs are validated rather than silently coerced, so a mistyped value produces an error instead of a plausible wrong answer. Availability percentages must fall between 0 and 100. Monthly requests must be a whole number up to one quadrillion. Monthly growth runs from −100% to 1,000%. Between 1 and 100 component availabilities can be combined. Forecast periods are limited to ten years. Revenue per hour must be non-negative.
A saved workspace holds the whole profile and its computed analysis, plus your notes and tags, in this browser’s local storage — 30-day expiry, up to 24 workspaces at 128 KiB each. Nothing is sent anywhere. Because the profile travels to the linked tools through the URL, the same service name, objective, and load figures follow you into a recovery or dependency exercise rather than being retyped with slightly different numbers each time.
Re-running the same profile monthly is where the forecast earns its keep. A single reading tells you where you are; a series of them tells you whether growth is accelerating, which is the thing that quietly destroys capacity plans built on last quarter’s rate.
Divide capacity by current load, take the natural logarithm, and divide by the natural logarithm of one plus the monthly growth rate. At 65% utilisation with 8% monthly growth that gives about 5.6 months. Enter the three numbers above and the tool does it, and flags the result when it falls inside six months.
Because traffic growth is normally a rate applied to a base that keeps increasing. Modelling it as a fixed number of requests per month understates future load and produces a runway that is too long — the error compounds precisely when it matters most, near the threshold.
Because in series every component has to work, so their availabilities multiply. Three components at 99.99%, 99.95%, and 99.9% combine to 99.84006%, which is below all three. Adding a dependency to a chain can only reduce availability, which is the case for treating every added integration as a reliability cost.
One you measured. A load test taken to the point of degradation, or an observed peak at which latency still met the objective. Vendor maximums and specification-derived calculations produce a forecast that looks fine until it isn’t.
Peak. Capacity is exhausted at the peak, and averages hide it — a service averaging 40% of capacity can saturate every weekday afternoon.
Growth is zero or negative, or current load is zero, so on the stated trajectory load never reaches capacity. It is a statement about the inputs, not a guarantee — revisit it whenever the growth rate changes.
No. Every calculation runs in your browser and saved profiles stay in local storage on this device. Nothing is transmitted and clearing site data removes them.
No. This and the rest of our planning tools are free and need no signup. For a deeper error-budget and burn-rate analysis use the SLA and SLO calculator; to map what a service actually depends on, see the dependency atlas.
For a time budget, the unavailable fraction is multiplied by the period length. For a request budget, the same fraction is multiplied by request volume and rounded down to a whole failed request.
In a series model every component must work, so availability values multiply. In a parallel model any component can satisfy the function, so the model subtracts the product of every component failure probability from one.
No. It is a compound-growth forecast from the supplied current load, tested capacity, and monthly growth. Seasonality, architecture changes, queuing, bottlenecks, and planned scaling can materially change the result.
Calculate SLA uptime percentages and error budgets, and convert between nines of availability and allowed downtime.
Analyze system availability, calculate MTBF, MTTR, MTTA, MTTD, MTTF metrics, estimate downtime costs, and improve system reliability.
Calculate optimal RTO/RPO targets, analyze downtime costs, and compare backup strategies with cost-benefit analysis
Conduct Business Impact Analysis to identify critical functions and recovery priorities