Score a serverless workload out of 100 on errors, throttles, latency margin, cold starts, memory fit and observability.
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.
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.
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.
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.
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.
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.
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.