Serverless Health Score Calculator
Score a serverless workload out of 100 on errors, throttles, latency margin, cold starts, memory fit and observability.
About Serverless Health Score Calculator
Each input is normalised to a 0-100 sub-score with a deliberately steep penalty curve — throttles cost a point per 0.01% because they mean dropped work, while cold starts cost only ten points per percent because they are a latency tax rather than a failure. The weights then combine them, and the weakest area is simply the lowest sub-score, which is where remediation buys the most improvement. Serverless workloads fail in ways a single availability number hides: a function can report 100% success while throttling a slice of traffic at the concurrency limit and silently dropping async events that have no failure destination.
Formulas
Serverless Health Score
score = 0.22 × error + 0.15 × throttle + 0.15 × timeout margin + 0.13 × memory fit + 0.15 × alarm coverage + 0.10 × cold start + 0.10 × failure-destination coverage.
- error sub-score
- 100 − error rate × 40, so 2.5% errors scores zero
- timeout margin
- 100 − (p99 ÷ timeout × 100) — a p99 near the timeout scores low
- memory fit
- 100 − |utilization − 70| × 2, penalising both waste and out-of-memory risk
Sub-scores
reliability = 0.45 × error + 0.30 × throttle + 0.25 × failure-destination coverage; efficiency = 0.45 × memory fit + 0.35 × timeout margin + 0.20 × cold start.
Worked example
With the default values below, Serverless Health Score Calculator returns Serverless Health Score of 74. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Invocation error rateaccepts 0–100 %
- 0.5 %
- Throttle rateaccepts 0–100 %
- 0.2 %
- p99 durationaccepts 1–900,000 ms
- 900 ms
- Configured timeoutaccepts 1–900,000 ms
- 3,000 ms
- Share of invocations that cold startaccepts 0–100 %
- 2 %
- Peak memory used of memory configuredaccepts 1–100 %
- 55 %
- Functions covered by alarmsaccepts 0–100 %
- 70 %
- Async functions with a dead-letter or failure destinationaccepts 0–100 %
- 60 %
Results
- Serverless Health Score
- 74 /100
- Grade
- C — Fair
- Reliability Sub-score
- 75
- Efficiency Sub-score
- 72
- Observability Sub-score
- 67
- Weakest Area
- Dead-letter or failure destination coverage
Step by step
- 1Values used
- 2Serverless Health Score
- 3Sub-scores
- 4Serverless Health Score= 74 /100
- 5Grade= C — Fair
- 6Reliability Sub-score= 75
- 7Efficiency Sub-score= 72
- 8Observability Sub-score= 67
- 9Weakest Area= Dead-letter or failure destination coverage
Assumptions and limits
- The result is derived only from the 8 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to whole numbers, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
How is Serverless Health Score calculated?
score = 0.22 × error + 0.15 × throttle + 0.15 × timeout margin + 0.13 × memory fit + 0.15 × alarm coverage + 0.10 × cold start + 0.10 × failure-destination coverage. Each input is normalised to a 0-100 sub-score with a deliberately steep penalty curve — throttles cost a point per 0.01% because they mean dropped work, while cold starts cost only ten points per percent because they are a latency tax rather than a failure. The weights then combine them, and the weakest area is simply the lowest sub-score, which is where remediation buys the most improvement.
Why does Serverless Health Score matter?
Serverless workloads fail in ways a single availability number hides: a function can report 100% success while throttling a slice of traffic at the concurrency limit and silently dropping async events that have no failure destination.
What values do I need to enter?
This calculator takes 8 inputs: Invocation error rate, Throttle rate, p99 duration, Configured timeout, Share of invocations that cold start, Peak memory used of memory configured, Functions covered by alarms, Async functions with a dead-letter or failure destination. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Why is memory utilization penalised for being too low?
Because you pay for memory you reserved, not memory you used. A function peaking at 20% of a 1 GB allocation is paying five times over, while one peaking above 90% is one payload spike away from an out-of-memory kill — around 70% balances the two.
What is a good score?
Above 75 is a workload you can operate without surprises. Below 60 usually means one specific gap — most often missing alarms or missing failure destinations — rather than broad decay, which is why the weakest-area output matters more than the total.