Cold starts versus warm capacity for voice workloads

TL;DR: Measure cold starts from resource creation to a representative request reaching a declared useful boundary. Keep startup delay, queue delay, and steady-state service time separate, then choose warm capacity using burst arrivals, occupancy, failure scenarios, and the caller's waiting budget.

---

The first call after a quiet period pauses. The next call responds quickly, and the team buys spare capacity before finding out whether the pause came from process startup, a connection handshake, a cache miss, or a slow dependency.

That purchase can help, but only if it keeps the delayed resource ready. A running process with an unloaded model, expired connection, or uninitialized language path can still put the first caller through the expensive work.

Define ready as an observable application state before comparing cold and warm runs. The latency boundary guide provides the companion discipline: the timing endpoint must name what the application or caller could observe.

This guide gives a matched experiment, a small synthetic trace analyzer, a capacity worksheet, and negative fixtures. It applies to voice applications evaluated with 60db Agent without assuming a private serving topology or claiming a measured product result.

As of November 2026, AWS Lambda's lifecycle documentation distinguishes initialization from reused execution environments. That is one public platform example; it does not establish startup duration or warm-state guarantees for a different voice deployment.

Table of contents

1. Define useful readiness
2. Measure separate startup paths
3. Design matched cold and warm cohorts
4. Run a synthetic trace analyzer
5. Turn arrivals into a capacity worksheet
6. Compare warm capacity policies
7. Diagnose slow first calls
8. Validate deployments and recovery
9. Report cost and uncertainty
10. Frequently asked questions
11. Choose the next experiment

Define useful readiness

A port accepting connections proves that a process has reached a listening state. It does not prove that the full voice path can accept a conversation and produce useful output under the intended configuration.

A readiness contract should name the artifact it exercises. For example, a representative synthetic request may verify that the configured model, language path, synthesis output format, and required dependencies can complete their declared initialization work.

Keep that request harmless. A readiness probe must not call real customers, perform a business write, consume an actual confirmation, or create user-visible tasks merely to discover whether a worker is ready.

For a streaming synthesis system, readiness can stop before physical playback while still testing the local output path. Name that endpoint so the report does not turn local writer acceptance into a claim that a caller heard speech.

The playback acknowledgment guide distinguishes those evidence levels. Choose one level for the startup experiment, then retain a separate end-to-end check for the transport and endpoint behavior that the probe omits.

Readiness also needs a lifetime. A worker that passed a probe before a dependency restart may no longer satisfy the same contract after its connection or credentials become invalid.

Revalidate what can change, and distinguish transient dependency failure from an initialization problem. Restarting a healthy process whenever a remote service is unavailable can increase cold starts while making recovery harder.

The Kubernetes probe guide separates startup, readiness, and liveness responsibilities. Use those distinctions when the deployment platform supports them, while making the application-specific readiness check your own explicit contract.

A warm worker can be busy. Ready capacity means slots that are both prepared and available under the workload's concurrency limit, so a fleet with running instances can still have no headroom for the next arrival.

A warm worker can also hold the wrong state. If one language path was exercised and another loads different resources, label readiness by the configurations it covers instead of applying a fleet-wide warm flag.

Use a readiness matrix when there are several material paths. Each row should identify the configuration, harmless probe input, expected output boundary, dependency scope, and event that invalidates the readiness evidence.

Keep the matrix small enough to maintain. It should cover real distinctions in initialization behavior, rather than every possible utterance or an expanding list of speculative future configurations.

The conceptual figure makes admission the final transition. A worker is useful warm capacity only after the declared ready condition holds and the admission controller can reserve a slot for the next call.

Measure separate startup paths

Start with a local monotonic clock for durations inside one process. Wall-clock timestamps help correlate events, but clock adjustments and separate hosts make raw subtraction unsafe unless the experiment establishes a synchronization model.

Record resource requested, resource available, process started, dependencies ready, representative request started, first useful output, and admission enabled as distinct events when the platform exposes them. Missing events remain unavailable, not zero.

Some stages overlap. Downloading an artifact and establishing a connection can happen concurrently, so adding every stage duration can overstate elapsed startup time unless the report describes the dependency order.

Use a timeline to identify the critical path. A long stage off that path can consume resources without determining readiness, while a short serialized stage at the end can still delay every first request.

Keep cold resource allocation separate from cold application state. A new machine with cached artifacts differs from an existing machine starting a fresh process, and both differ from a running process opening its first provider connection.

Keep cache state explicit too. A warm model with a cold response cache can be slower than a warm model with a hot cache, but that difference is not evidence that the process itself started slowly.

The cache-key guide explains why reuse depends on context. For startup experiments, use a compatible cache condition across cohorts or treat cache warmth as its own controlled factor.

Voice workloads add transport state. Session establishment, media negotiation, audio-device permission, carrier routing, and first-media behavior can affect the first call even when compute is ready.

The WebRTC, WebSocket, and SIP comparison provides those transport boundaries. Do not combine a browser permission prompt with model initialization and label the total as a server cold start.

Name every timing pair. "First output minus request admission" is a useful duration; "latency" without endpoints invites comparisons between unrelated parts of the path.

Store the workload version and deployment revision with each row. An optimization that changes prompt size, model settings, or output length at the same time as warm capacity does not isolate the effect of warming.

Retain failures in the same experiment ledger. A startup that never reaches readiness has no finite readiness duration, so record its timeout or error disposition rather than dropping it from the dataset or substituting the timeout threshold as a successful observation.

Design matched cold and warm cohorts

A cold cohort needs a reproducible reset condition. "First request today" is too vague because the process may be reused, the dependency may remain connected, and local artifacts may survive from an earlier run.

State exactly which state is reset. For example, process-cold can mean a newly started application process with a declared artifact-cache condition, while dependency-cold can mean a fresh connection under an otherwise running process.

A warm cohort needs evidence too. Record the readiness probe or preceding representative request that establishes warmth and the elapsed idle interval before the measured request.

Warmth can decay. Idle resource eviction, credential expiry, connection timeout, and autoscaling can invalidate different parts of the path on different schedules, so test more than one idle interval when that behavior matters.

Pair each cold workload with a matching warm workload. Keep input size, language, output boundary, dependency configuration, concurrency level, and regional placement the same within the pair.

Randomize or alternate cohort order when time-dependent effects are plausible. Running all cold tests during a noisy deployment and all warm tests afterward makes time of day a confounder rather than an experimental detail.

Use an isolated environment with consented synthetic traffic. The bursty arrival guide explains how to retain offered work and generator limits, which becomes useful when testing startup during a scale-out wave.

A single request experiment answers startup mechanics. A burst experiment answers whether warm capacity absorbs arrivals while new resources become useful, so run both and report them as different workloads.

Do not compare successful warm requests against every cold attempt. Use outcome counts for the full cohort, then report latency distributions among the subset that reached the chosen boundary.

The distinction prevents survivorship bias. A policy that rejects difficult first calls can have a lower successful-request percentile while providing a worse experience for the offered population.

Public community questions help locate the practical gap. A discussion about model unloading and cold starts asks about keeping local model resources available; it illustrates a real configuration question, not a benchmark result that can be transferred to your system.

Record the exact reset procedure in the experiment report. Another engineer should be able to reproduce the state being compared without guessing which container, dependency, or cache was supposed to be cold.

Run a synthetic trace analyzer

The reference below analyzes a narrow local trace and computes peak overlap for synthetic occupancy intervals. It validates the declared clock domain, rejects missing or reversed stages, and keeps raw rows available beside derived durations.

The trace analyzer does not infer whether a real worker was warm. The harness supplies that cohort label after the experiment establishes its reset or readiness condition, and every duration in the fixture is synthetic.

Run the complete fence with Python 3.11 or later as python cold_warm_reference.py. The output confirms fixture behavior, not live startup performance.

from dataclasses import dataclass, FrozenInstanceError
import math


def number(value):
    if type(value) not in (int, float) or not math.isfinite(value):
        raise ValueError("expected a finite timestamp")
    return value


@dataclass(frozen=True, slots=True)
class Trace:
    receiver: str
    clock: str
    cohort: str
    requested: float
    ready: float
    arrived: float
    admitted: float
    first_output: float

    @classmethod
    def capture(cls, raw):
        fields = ("receiver", "clock", "cohort", "requested", "ready",
                  "arrived", "admitted", "first_output")
        if type(raw) is not dict or set(raw) != set(fields):
            raise ValueError("trace schema mismatch")
        for name in fields[:2]:
            if type(raw[name]) is not str or not raw[name]:
                raise ValueError("identity and clock are required")
        if raw["cohort"] not in ("cold", "warm"):
            raise ValueError("unknown cohort")
        times = [number(raw[name]) for name in fields[3:]]
        requested, ready, arrived, admitted, first_output = times
        if not (requested <= ready <= admitted <= first_output and
                arrived <= admitted):
            raise ValueError("stage order is invalid")
        return cls(raw["receiver"], raw["clock"], raw["cohort"], *times)


def durations(trace, expected_clock):
    if trace.clock != expected_clock:
        raise ValueError("clock domain mismatch")
    return {"raw": trace,
            "startup": trace.ready - trace.requested,
            "queue": trace.admitted - trace.arrived,
            "service": trace.first_output - trace.admitted}


def peak_overlap(intervals):
    events = []
    for start, end in intervals:
        number(start)
        number(end)
        if end <= start:
            raise ValueError("occupancy interval must be positive")
        events.extend(((start, 1), (end, -1)))
    active = peak = 0
    for _, change in sorted(events):
        active += change
        peak = max(peak, active)
    return peak


def rejected(action):
    try:
        action()
    except (ValueError, FrozenInstanceError):
        return
    raise AssertionError("invalid fixture accepted")


# Synthetic seconds in one local monotonic clock domain.
raw = dict(receiver="synthetic-worker-a", clock="local-monotonic-a",
           cohort="cold", requested=0.0, ready=4.0, arrived=0.0,
           admitted=4.25, first_output=4.75)
t = Trace.capture(raw)
r = durations(t, "local-monotonic-a")
assert (r["startup"], r["queue"], r["service"]) == (4.0, 4.25, 0.5)
assert r["raw"] is t and r["raw"].receiver == "synthetic-worker-a"
raw["ready"] = 100.0
assert t.ready == 4.0
rejected(lambda: setattr(t, "ready", 0.0))
rejected(lambda: durations(t, "different-host-clock"))
rejected(lambda: Trace.capture(dict(raw, ready=None)))
rejected(lambda: Trace.capture(dict(raw, ready=5.0)))
rejected(lambda: Trace.capture(dict(raw, ready=float("nan"))))
rejected(lambda: Trace.capture(dict(raw, cohort="unknown")))
rejected(lambda: Trace.capture(dict(raw, receiver="")))
missing = dict(raw)
del missing["ready"]
rejected(lambda: Trace.capture(missing))
rejected(lambda: Trace.capture(dict(raw, ready=4.0, arrived=5.0)))
warm = Trace.capture(dict(raw, cohort="warm", ready=4.0, arrived=60.0,
                          admitted=60.0, first_output=60.5))
assert durations(warm, warm.clock)["queue"] == 0.0
assert durations(warm, warm.clock)["service"] == 0.5
zero = Trace.capture(dict(raw, ready=0.0, arrived=0.0, admitted=0.0, first_output=0.0))
assert durations(zero, zero.clock)["startup"] == 0.0
assert peak_overlap([]) == 0
assert peak_overlap([(0, 2), (1, 3), (2, 4)]) == 2
assert peak_overlap([(0, 1), (1, 2)]) == 1
assert peak_overlap([(0, 3), (0, 3), (0, 3)]) == 3
rejected(lambda: peak_overlap([(1, 1)]))
rejected(lambda: peak_overlap([(2, 1)]))
rejected(lambda: peak_overlap([(0, float("inf"))]))
print("cold/warm trace and overlap fixtures passed")

The interval convention is half-open: a slot released at time t can serve an arrival at the same time. Sorting end events before start events implements that convention, and the equal-boundary fixture prevents a later refactor from counting artificial overlap.

The worker startup request and the call arrival are separate events. Startup is readiness minus the worker request; queue delay is admission minus call arrival, so an idle warm worker does not create artificial waiting. A call arriving before readiness can include startup in its queue delay. These durations overlap and must not be added as independent stages.

The trace's zero values remain zero. Missing readiness is rejected because the function cannot compute startup duration from an absent event; replacing it with zero would make an unobserved stage look instantaneous.

The original receiver and clock identity remain attached to the derived record. That allows a report to recompute the durations and prevents a downstream consumer from subtracting timestamps from unrelated hosts without noticing the mismatch.

Python's time documentation defines the monotonic clock's purpose. In a real adapter, take all timestamps for one local duration from the same supported clock and record cross-host spans using an explicit tracing model.

The published function is intentionally an analyzer, not a serving SDK. Authentication, resource creation, queue control, and endpoint playback remain responsibilities of the experiment harness and application adapters.

Turn arrivals into a capacity worksheet

Warm capacity must cover work that arrives before replacement or additional capacity becomes useful. A mean arrival rate alone misses the shape of that interval, especially when calls arrive together after a campaign or an outage.

Begin with an arrival ledger. Each row records scheduled arrival, actual arrival, admission disposition, occupancy start, occupancy end, configuration class, and the useful output boundary observed.

Occupancy is the time the constrained resource remains reserved. For one application it can be the entire call; for another it can be a model request or a synthesis segment, so do not use call duration as a universal resource-holding time.

The synthetic overlap function computes peak simultaneous occupancy for a supplied interval set. It does not account for queue delay, packing inefficiency, memory fragmentation, or per-configuration capacity differences unless those are represented in the input model.

Use the peak as one worksheet input, then apply the operating margin and failure policy that your measured workload justifies. An arbitrary percentage of spare capacity is less informative than a scenario showing which arrivals remain admissible when a worker disappears.

A useful worksheet includes the warm slot count, measured startup distribution, offered burst profile, occupancy distribution, maximum queue age, and a fallback disposition. It also names the assumptions that make the slot abstraction valid.

For example, if one slot can serve only one active synthesis job, model inference concurrency belongs in a separate row. Combining both into a single "calls per worker" number hides which resource saturates first.

The admission control guide turns these limits into explicit decisions. Warm capacity reduces the chance of waiting; admission control determines what happens when ready capacity is still insufficient.

Include the startup exposure window. Arrivals during resource creation need existing slots, a bounded queue, or a fallback, because requested capacity is not available capacity.

Include failure exposure separately. A policy that absorbs a normal burst can still fail when one warm worker drains or a regional dependency becomes unavailable during that burst.

Choose the slot boundary by observing contention. If two simultaneous requests interfere because they share one memory allocation budget, the slot model must represent that budget or declare its approximation; counting threads or open sockets will not explain the resource that limits useful work.

A synthetic worksheet can begin with a recorded arrival list and an occupancy interval for each admitted request. Replay the same list against several candidate warm floors, preserving equal-time ordering and each request's deadline, then record how many arrivals start immediately, wait within budget, expire, or receive fallback.

Do not draw a smooth performance curve from that exercise unless the model supports it. A discrete replay answers the named scenarios under its assumptions, and the next live experiment should test the candidate policy at the region where the disposition changes.

Use several workload classes when their occupancy differs materially. Short public-information calls and long tool-heavy calls can have the same arrival rate while occupying very different amounts of the constrained resource.

Averages help estimate steady-state demand under stated conditions. They do not establish burst protection, tail latency, or a guarantee that every arrival can start before its deadline.

Validate the worksheet with a replay of synthetic arrival times and measured occupancy samples. Preserve the sample source, units, and pairing rule so the resulting estimate can be reproduced instead of appearing as an unexplained capacity recommendation.

Compare warm capacity policies

A fixed warm floor keeps a declared minimum ready. Scheduled warming prepares for known demand windows, while reactive scaling requests resources after a measured signal crosses a threshold.

These policies can coexist. The question is how each one covers the interval between the first excess arrival and useful additional capacity, including the uncertainty in detection and startup.

The Kubernetes autoscaler documentation describes a control loop driven by metrics. A replica target produced by that loop is still different from an application slot that has passed its readiness contract.

A fixed floor has an idle cost. Scheduled warming risks forecasting errors and missed schedules, while reactive scaling exposes early arrivals to the combined detection, provisioning, and readiness delay.

The table compares policy responsibilities under this guide's definitions. A check means the policy directly addresses the stated condition; a cross means another mechanism is required, and deployment details can change the outcome.

Provider features need the same boundary check. AWS provisioned concurrency documentation describes pre-initialized execution environments and version or alias configuration; it does not promise that every downstream voice dependency is warm.

Verify that requests reach the prepared version or pool. A correctly configured warm resource that receives no traffic cannot improve the caller's path, and an experiment should expose routing mistakes rather than averaging them away.

Track pending preparation as a separate inventory. A requested worker that has not passed readiness belongs in the startup ledger, while an admitted call belongs in active occupancy, and a ready free slot belongs in available capacity; adding those categories produces a resource total but does not produce a useful admission limit.

This distinction matters during retries of the provisioning operation. If the first request to create capacity has an unknown outcome, reconcile its identity before creating another resource, otherwise a temporary control-plane timeout can leave duplicate prepared resources and misleading cost measurements.

For a scheduled warm window, verify both edges. Confirm capacity is ready before the first expected arrival, then confirm scale-down waits for active work to drain and does not discard the readiness evidence needed to explain the final calls in the window.

Keep the policy simple until a measured failure requires more control. A fixed floor plus an explicit queue-age limit can be easier to operate than several overlapping warmers whose combined behavior is difficult to reproduce, provided that the measured workload and approved fallback fit that smaller policy.

Choose policy using the workload and the allowed fallback. A service that can offer a truthful callback has a different waiting budget from an active conversation that needs to preserve a caller's turn without an unexplained pause.

The waiting speech guide helps define that fallback language. A capacity delay does not justify claiming that an operation completed or that a response is already on its way when the system has not established either fact.

Diagnose slow first calls

First determine whether the worker was ready before the call arrived. If it was not, inspect the startup timeline; if it was, inspect queue wait and dependency service time before changing the warm floor.

A first-call pause after a long idle interval can come from connection expiry. Increasing process count may create more idle connections with the same behavior, so measure connection establishment and reuse directly.

A first-call pause after a deployment can come from artifact loading or routing to an unprepared version. Compare the route and version attached to each trace with the resource that passed readiness.

A first-call pause in one language can come from an unexercised configuration path. Use the readiness matrix to identify which configuration was warm rather than treating every process as equally prepared.

A pause during a burst often indicates capacity queueing. The bursty load testing guide explains why a flat rate and an aggregate percentile can conceal those short saturation windows.

Check the generator too. If it cannot create the scheduled load, a low observed queue depth can reflect missing offered work rather than enough warm capacity.

Use the observability guide to join safe event identities across admission and service boundaries. Keep local clocks distinct, and attach a reason when an event is missing instead of manufacturing a duration.

Look for retries that hide initial failures. An apparently fast warm response can be the second attempt after a slow initialization failure, and excluding that first attempt changes the user-visible waiting time.

Retain both attempt-level and call-level outcomes. The former diagnoses the component; the latter represents what the caller experienced across the bounded retry policy.

Watch terminal state during diagnosis. A request that timed out or was canceled while waiting must not become active again when a late startup completion callback finally arrives.

The batch cancellation guide explains that late work can be discarded per owner without stopping unrelated shared execution. Startup and capacity experiments should preserve the same ownership discipline.

Validate deployments and recovery

Warm capacity changes during deployments. Old workers can be draining while new workers are running but unready, so a replica count can remain constant while useful available slots temporarily fall.

Measure the transition with active synthetic conversations. Admit new work only to ready slots, preserve existing conversation ownership through draining, and record the interval during which the deployment has reduced spare capacity.

The shutdown semantics guide separates admission closure from termination. Reusing that distinction prevents a deployment from counting a draining worker as available for new calls or terminating it while active calls still depend on it.

Test rollback with the same readiness contract. A rollback that restores old code but routes traffic before its dependencies are prepared repeats the first-call failure under a different revision.

Test cache loss separately from process replacement. If a shared cache disappears, running workers can face expensive misses together, which resembles a cold fleet from the dependency's perspective even though their processes never restarted.

Test credential and connection renewal without forcing unnecessary restarts. The recovery mechanism should reestablish the invalid resource and update readiness evidence rather than erasing healthy state by default.

The figure separates useful categories. Ready and free can admit; ready and busy consumes existing capacity; starting cannot yet serve; draining preserves current work while refusing new admission under the declared policy.

An autoscaler should receive a signal that reflects useful capacity. Raw process count can be one input, but queue age, available slots, dependency readiness, and pending startup resources explain different parts of the control loop.

Do not make readiness depend on every optional dependency. A degraded mode can remain useful if the product contract permits it, but the admission decision must know which workload classes the degraded worker can safely serve.

Use a failure injection with one lost warm worker. Observe rejection, queue expiry, fallback, recovery time, and whether unrelated calls retain their media and task state throughout the event.

A successful recovery report includes the work that never started. Dropping rejected arrivals from the denominator makes a capacity policy appear more reliable as it refuses more callers.

Report cost and uncertainty

Compare policies over the same operating interval. Include idle prepared resources, startup work, served work, failed attempts, and the costs of fallback paths that the experiment can observe.

The cost per successful task guide gives a useful denominator. A cheaper infrastructure hour does not establish a cheaper successful task if the policy causes more abandoned or expired conversations.

Keep currency, billing units, and provider-specific charges separate from the synthetic worksheet. This guide does not supply a universal price or an invented return on investment for warm capacity.

Report readiness duration and admitted-request response duration separately. The first measures resource preparation; the second measures service after admission, and both can matter to the caller depending on arrival time.

State sample counts for each cohort and outcome. If a cold cohort contains too few successful observations to support a stable tail estimate, publish the raw distribution or a bounded descriptive summary instead of implying statistical certainty.

Retain configuration details that affect reproducibility: model and artifact revisions, language path, transport boundary, resource class, concurrency limit, cache condition, reset procedure, and experiment time window.

Separate measured data from modeled scenarios. Peak overlap from synthetic intervals is a calculation under assumptions, while observed queue delay from a real test is evidence about that specific environment.

A percentile needs a population definition. A startup percentile over new processes is different from a response percentile over admitted calls, and either can look healthy while a minority of offered calls never reach the relevant endpoint.

When a request times out, retain the timeout as an outcome and the observed waiting lower bound as separate evidence. Treating that lower bound as a completed duration creates a result that the experiment did not observe, while removing the request makes the remaining distribution appear faster.

Keep the number of independent startup events visible. Many requests served by the same newly prepared process are useful for post-start behavior, but they do not create many independent cold-start observations; the preparation event is shared across those requests.

Account for idle intervals explicitly. A test that sends one request immediately after warming answers a narrower question than a test that waits through the connection's idle period, and the two rows should remain distinguishable in the report.

Use repeated matched pairs across the operating window when background conditions vary. Keep each pair's order, reset evidence, and environment version so an apparent improvement can be inspected for a deployment or routing change that occurred between cohorts.

A practical decision record can fit in a short table. For each candidate policy, record the ready floor, startup condition, offered burst, successful boundary count, expired count, fallback count, idle resource time, and unknown fields; leave an unmeasured cell marked unavailable rather than borrowing a number from a different platform.

The cost comparison needs an interval long enough to include preparation and idle time. Measuring only the busy portion of a scheduled warm window excludes the expenditure that made the resource ready before the first arrival, while measuring only an idle window excludes its useful work.

Review the report with the operator who owns the fallback. If the policy expires work after a waiting budget, the caller experience and downstream cleanup are part of the decision, even when the infrastructure chart shows a lower cost or a faster successful-request percentile.

Also review the configuration owner. A warmer that sends synthetic requests through the wrong alias can produce reassuring probe logs while real traffic takes an unprepared path; retain a route identity that can join probe evidence to actual admission without exposing customer data.

A capacity recommendation should name the next uncertainty it depends on. If startup under dependency failure is unmeasured, say so and keep the fallback conservative until the failure experiment supplies evidence.

For an application using 60db Agent, attach conclusions to documented public boundaries. A generic local trace analyzer cannot establish product internals, carrier behavior, device performance, or a production service-level guarantee.

---

Frequently asked questions

What is a cold start in a voice workload?

A cold start is preparation work on the request path for a resource that is not yet ready under a declared contract. Specify whether that means a new machine, process, model state, connection, or application configuration, because those conditions have different reset procedures.

Is a running process warm capacity?

Only when it has passed the relevant readiness contract and has an available slot. A running process can still be initializing a dependency, serving another call, or draining, so process count alone does not establish capacity for the next arrival.

Should we measure first token or first audio?

Use the boundary that answers the experiment's question and name it precisely. First token diagnoses one model boundary, while first received audio and endpoint playback answer different questions about the voice path; avoid comparing those durations as if they were interchangeable.

Why does the first call remain slow after warming?

The delayed resource may not be the one you warmed. Inspect connection establishment, cache state, routing, language-specific initialization, media setup, and queue wait before assuming that the configured warm pool failed to keep its own resource ready.

Can a health check establish readiness?

It can when its implementation exercises the declared harmless readiness path. A generic status endpoint or open port usually proves less, so document what the probe validates and what remains outside its boundary.

What is the difference between startup and readiness probes?

Startup probes allow initialization to complete under the deployment platform's lifecycle. Readiness determines whether traffic should be admitted; liveness addresses whether a process needs recovery, and those responsibilities should not be combined without a reason.

How many warm slots do we need?

Use the observed arrival and occupancy workload, startup exposure window, queue-age budget, and failure scenarios. There is no universal slot count because a call, a model request, and a synthesis job can hold different constrained resources for different durations.

Is average arrival rate enough for planning?

It helps estimate steady-state demand under stated assumptions. Burst protection requires arrival timing and occupancy distributions, because several calls can arrive together before reactive scaling produces useful capacity even when the long-run average remains low.

Does reactive autoscaling remove cold starts?

Reactive scaling requests capacity after a signal changes, so early excess arrivals still face detection and preparation delay. A warm floor, a bounded queue, or an explicit fallback can cover that exposure window according to the application's waiting contract.

When does scheduled warming make sense?

It fits predictable demand windows when the schedule prepares capacity early enough and readiness is verified before arrivals. Keep a policy for unexpected demand and schedule failures rather than assuming the forecast covers every call.

How should we compare cold and warm cohorts?

Use matched workloads and the same response boundary, with explicit reset and warm-state evidence. Retain every attempt's outcome, then compare latency among requests that reached the boundary while also reporting failures, expiries, and rejections.

Should failed startups appear in latency percentiles?

They need their own outcome count because they never reached the successful timing endpoint. Do not silently exclude them from the experiment ledger or pretend that a timeout threshold is an observed successful readiness duration.

Why use a monotonic clock?

It supports local elapsed-duration measurement without wall-clock adjustment effects. Keep each subtraction inside a declared clock domain, and use an explicit synchronization or tracing model when a measurement crosses processes or hosts.

Why retain raw trace rows?

Raw rows preserve identities, endpoints, and missing evidence so another engineer can recompute the derived durations. A report containing only an average startup number cannot expose clock mismatches, stage ordering errors, or differences in workload composition.

Does the overlap function predict production capacity?

It computes peak overlap for the supplied synthetic half-open intervals. Production planning still needs measured occupancy, queue and packing assumptions, resource-specific limits, dependency behavior, and validation under the actual workload mix.

Can cache loss create cold behavior without restart?

Yes. Running processes can suddenly recompute expensive misses together after a cache loss or namespace change. Treat that as a separate workload condition so process warmth does not hide dependency demand or the need for bounded admission.

What should happen to a caller who waits too long?

Apply the declared expiry and fallback policy, and preserve the terminal disposition when late readiness arrives. A truthful fallback can offer another path, but it should not claim that work completed or reactivate a canceled conversation.

How do deployments change warm capacity?

Draining old workers and initializing new ones can reduce available slots while the total replica count looks stable. Measure useful readiness and admission through the transition, including rollback and one-worker-loss scenarios.

Is warm capacity always more expensive?

It adds prepared idle resource cost under many billing models, but the total outcome depends on startup work, failures, retries, and successful tasks. Compare policies over the same workload and interval rather than assuming that lower idle spend means lower cost per useful result.

What remains unmeasured in this guide?

The examples validate analyzer logic with synthetic timestamps and occupancy intervals. They do not measure real cold-start duration, provider performance, acoustic playback, live carrier behavior, or the private implementation of 60db Agent.

Choose the next experiment

Define one useful readiness boundary and one reproducible cold reset. Pair it with a warm condition that has explicit evidence, then run the same harmless workload through both conditions while retaining every outcome.

Use the trace analyzer to keep stage durations and identities inspectable. Use the overlap worksheet to connect arrivals with occupancy, then validate the resulting policy during a burst and a deployment transition.

Before buying more spare capacity, identify the first delayed stage. Prepare the resource that causes that delay, preserve a bounded waiting policy for excess arrivals, and report the remaining uncertainty at the public boundary your application can observe.