Reliability Engineering Lab
Model SLO budgets, architecture availability, downtime impact, and capacity growth in a reusable local service workspace.
Capacity Headroom Forecast: When Does This Service Run Out?
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.
The Forecast Formula
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.
What Counts as Capacity
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.
The Rest of the Service Profile
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.
Findings the Model Raises
| 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.
Input Bounds
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.
Saving a Service Profile
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.
How to Forecast Capacity Headroom
- Name the service and enter the objective you are actually held to.
- Enter current peak load and tested capacity in the same unit. Use a measured capacity figure, not a datasheet number.
- Enter monthly growth from your own traffic history — ideally the last six months, so a single spike does not set the rate.
- Select Recalculate and read months to capacity alongside the utilisation percentage.
- Compare the runway to your lead time for adding capacity. If the runway is shorter, start now.
- Fill in observed availability and component availabilities to model whether the architecture can even reach the objective.
- Save the profile and re-run it monthly, watching whether the growth rate itself is rising.
Frequently Asked Questions
How do I calculate when a service will run out of capacity?
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.
Why does the forecast assume compound rather than linear growth?
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.
Why is my series availability worse than my worst component?
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.
What capacity number should I enter?
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.
Should I use peak load or average load?
Peak. Capacity is exhausted at the peak, and averages hide it — a service averaging 40% of capacity can saturate every weekday afternoon.
The forecast says “No crossing”. What does that mean?
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.
Is anything sent to a server?
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.
Do I need an account?
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.
Capacity Headroom Forecast: When Does This Service Run Out?
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.
The Forecast Formula
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.
What Counts as Capacity
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.
The Rest of the Service Profile
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.
Findings the Model Raises
| 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.
Input Bounds
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.
Saving a Service Profile
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.
How to Forecast Capacity Headroom
- Name the service and enter the objective you are actually held to.
- Enter current peak load and tested capacity in the same unit. Use a measured capacity figure, not a datasheet number.
- Enter monthly growth from your own traffic history — ideally the last six months, so a single spike does not set the rate.
- Select Recalculate and read months to capacity alongside the utilisation percentage.
- Compare the runway to your lead time for adding capacity. If the runway is shorter, start now.
- Fill in observed availability and component availabilities to model whether the architecture can even reach the objective.
- Save the profile and re-run it monthly, watching whether the growth rate itself is rising.
Frequently Asked Questions
How do I calculate when a service will run out of capacity?
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.
Why does the forecast assume compound rather than linear growth?
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.
Why is my series availability worse than my worst component?
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.
What capacity number should I enter?
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.
Should I use peak load or average load?
Peak. Capacity is exhausted at the peak, and averages hide it — a service averaging 40% of capacity can saturate every weekday afternoon.
The forecast says “No crossing”. What does that mean?
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.
Is anything sent to a server?
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.
Do I need an account?
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.
Strategic Security Planning
Get C-level security guidance to align your security investments with business goals.
Frequently Asked Questions
Common questions about the Reliability Engineering Lab
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.
Explore More Tools
Continue with these related tools
ℹ️ Disclaimer
This tool is provided for informational and educational purposes only. All processing happens entirely in your browser - no data is sent to or stored on our servers. While we strive for accuracy, we make no warranties about the completeness or reliability of results. Use at your own discretion.