Serverless Health Score Calculator
Score a serverless workload out of 100 on errors, throttles, latency margin, cold starts, memory fit and observability.
Inputs
Aim for roughly 70% — lower wastes GB-seconds, higher risks out-of-memory errors.
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
Values used
Invocation error rate = 0.5000 %; Throttle rate = 0.2000 %; p99 duration = 900 ms; Configured timeout = 3,000 ms; Share of invocations that cold start = 2 %; Peak memory used of memory configured = 55 %; Functions covered by alarms = 70 %; Async functions with a dead-letter or failure destination = 60 %
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.
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.
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
How it works
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.
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.