toolbox
Home / Startups & Digital Business / Serverless Function Capacity Needs Estimator

Serverless Function Capacity Needs Estimator

The Serverless Function Capacity Needs Estimator estimates the concurrency required to handle a peak request rate at a given average function duration, then adds an optional headroom allowance. It also translates the concurrency requirement into a rough daily peak-throughput reference so teams can sanity-check the scale of the traffic assumption.

This is useful when planning reserved or provisioned concurrency, setting account limits, or assessing whether a sudden traffic increase could create throttling pressure. The result is a workload estimate, not a guarantee of platform behavior; retries, burst patterns, cold starts, downstream bottlenecks, and provider-specific scaling limits can all change real capacity requirements.

Peak workload profile

req/s
ms
%
concurrency
Result
—
Recommended concurrency capacity
Base concurrency needed—
Gap vs current limit—
Peak-rate daily equivalent—

1. Measure the peak request rate
Use a peak rate that represents the traffic interval you need to survive, not the monthly average.

2. Enter average execution duration
Use the average time one invocation remains active during the peak window. Longer-running functions hold concurrency for more time.

3. Add operating headroom
Headroom provides a planning buffer for normal variability above the measured or forecast peak.

4. Enter the current concurrency limit
Use the limit or provisioned capacity you want to compare with the calculated requirement.

5. Review the capacity gap
A positive gap indicates additional concurrency may be needed under the entered assumptions; a negative value means the current limit is above the estimate.

Base concurrency = Peak requests per second × Average duration in seconds

Recommended concurrency = Base concurrency × (1 + Headroom rate)

The recommended result is rounded up to a whole concurrent execution. This relationship assumes requests are distributed consistently enough that average duration is representative during the peak interval.

What the result means

The result is the estimated whole-number concurrency capacity needed to serve the entered peak workload plus headroom.

Burst quotas, reserved capacity for other functions, asynchronous retries, and downstream service limits should be reviewed separately.

Given
Peak rate = 240 requests/second
Average duration = 320 ms
Headroom = 30%
Current concurrency limit = 100

Calculation
Base concurrency = 240 × 0.320 = 76.8
With headroom = 76.8 × 1.30 = 99.84
Round up to 100.

Result
Recommended capacity = 100 concurrent executions.

Under these assumptions, the current limit of 100 is exactly at the rounded planning requirement.

Why does duration affect concurrency?

Each active invocation occupies concurrency for the time it runs. At the same request rate, a longer duration means more invocations overlap.

Should I use average or p95 duration?

Average duration matches the basic concurrency relationship, but a conservative planning exercise may use a higher representative duration. Be consistent about what the chosen value represents.

Does the headroom percentage replace autoscaling?

No. Headroom is only a planning buffer in the estimate. Actual scaling behavior, quotas, ramp rates, and platform controls still determine whether traffic is served without throttling.

What if traffic arrives in very short bursts?

A requests-per-second average can understate sub-second bursts. For highly bursty workloads, examine fine-grained traffic data and provider burst limits in addition to this estimate.

Is current concurrency limit the same as provisioned concurrency?

Not necessarily. A platform account limit, reserved concurrency, and provisioned concurrency can represent different controls. Enter the capacity figure that you specifically want to compare against the requirement.