Startup Time Budget
A startup time budget caps the time from process launch to serving traffic, so the deployment, autoscale, and crash-loop do not amplify a slow init into an outage.
Definition
A startup time budget is the target maximum for the interval from process start to ready-to-serve, designed so that autoscale-up, deploy-rollback, and crash-loop recovery meet their SLOs, with the init work prioritized: only the work needed to serve the first request runs before the readiness probe passes.
Context and scope
Applied in serverless, containerized services, and any system where a cold start is on the user path or the autoscale path.
Common misconceptions
- A fast startup is just lazy init — lazy init helps; the budget is met by deferring non-critical init, precompiling, and avoiding heavy I/O on the start path
- Startup time only matters for serverless — it matters for autoscale, deploys, and recovery everywhere; a 60s startup is a 60s autoscale delay on any platform
Anti-patterns
- Running every initialization including warmup of rarely-used features, so the readiness probe passes after the full init
- Loading every config file and every plugin synchronously on start, so a slow filesystem adds seconds to every cold start
Related concepts
Authoritative source
What it is
A startup time budget is the target maximum for the interval from process start to ready-to-serve, designed so that autoscale-up, deploy-rollback, and crash-loop recovery meet their SLOs, with the init work prioritized: only the work needed to serve the first request runs before the readiness probe passes. Applied in serverless, containerized services, and any system where a cold start is on the user path or the autoscale path. Performance is a distribution, not a number: the tail determines user experience, and the mean hides the outliers that cause abandonment.
How it works
Measurement targets percentiles at the workload’s actual concurrency, not a single sequential run. The fast path is kept fast by deferring work that is not on it — lazy initialization, coalescing writes, avoiding allocation in hot loops. Profiling finds the bottleneck; micro-optimization without a profile optimizes the wrong thing. Constant factors matter, but algorithmic complexity dominates as scale grows.
When to optimize and pitfalls
Optimize when a measurement shows a concrete cost — latency budget burn, compute spend, user-visible jank. The pitfall is optimizing for the benchmark rather than the workload: a synthetic test that does not reproduce the production access pattern produces a local maximum that hurts globally. Another is trading memory for speed without accounting for the GC or eviction cost the extra allocation introduces.