A production readiness checklist is a set of evidence-backed launch gates for a software service. A service is ready when named owners can show that it meets defined user outcomes under the planned workload, detects failures quickly, and has tested containment and recovery paths. Product readiness asks whether a product or feature is ready for customers and the market; a manufacturing production-readiness review covers physical production. This guide covers software operations first, then applies the same gates to a voice agent.
How to use this production readiness checklist
Choose a risk tier before you review individual checks. Base it on the user promise and SLO, service criticality, blast radius and downtime impact, data sensitivity, regulatory exposure, and how easily you can reverse a bad release. A limited internal tool and a service that moves money should share the same baseline areas, but their required checks and depth of proof will differ.
Give every checklist row one of five states:
- Open: The owner has not completed the review yet.
- Pass: The owner linked current evidence that satisfies the criterion.
- Blocked: The criterion is required and has not been met.
- Time-limited exception: An authorized person accepted the residual risk for a defined period.
- Not applicable: The owner explained why the criterion does not apply.
For each pass, attach dated evidence such as a test result, dashboard, alert exercise, runbook, data-flow diagram, restore rehearsal, or approved decision record. Mercari's public production readiness review process uses this practical rule: even a checked not applicable item needs an explanation.
An exception should record the risk, mitigation, remediation plan and owner, approver, expiration date, and re-review trigger. It is not another way to say pass.
The template does not prescribe universal latency, availability, recovery, traffic, canary, or cost thresholds. Set those from the service's user promises, workload, risk, economics, and applicable obligations.
Production readiness checklist template
Copy this table into the team's issue tracker or change record. Add columns for Blocker?, Evidence date, and Exception expires, then replace the examples with service-specific links and targets.
| Area | Pass criterion | Status | Required evidence | Owner |
|---|---|---|---|---|
| Scope | Critical user journeys, expected outcomes, exclusions, and launch cohort are documented | Open | Approved scope and acceptance criteria | Product and engineering |
| Architecture | The current request and data flows identify components, third parties, regions, failure domains, and state | Open | Architecture and data-flow diagrams | Technical owner |
| Dependencies | Limits, service expectations, deprecations, escalation paths, and failure behavior are known for critical dependencies | Open | Dependency register and failure review | Technical owner |
| Ownership | Business, technical, on-call, security/privacy, support, cost, and go/no-go authority are named | Open | Ownership and escalation record | Engineering lead |
| Blast radius | The maximum affected cohort and a safe degraded mode are defined | Open | Risk assessment and degraded-mode plan | Decision owner |
| User outcomes | The service has a small set of user-visible indicators for availability, latency, correctness, durability, or throughput where relevant | Open | Service-level indicator definitions | Product and reliability owners |
| Reliability targets | Each service-level objective (SLO) states its measurement source, window, workload classes, target, owner, and approver | Open | SLO document and dashboard | Reliability owner |
| Reliability action | The team has agreed what happens when the error budget or another launch limit is exhausted | Open | Error-budget or stop-policy record | Product and engineering |
| Capacity forecast | Steady state, launch spikes, bursts, growth, and tail workload have been estimated | Open | Forecast and assumptions | Capacity owner |
| Load behavior | Predeployment load and failure tests cover expected traffic shapes and constrained resources | Open | Test report with bottleneck and recovery data | Engineering |
| Admission control | Rate limits, queues, timeouts, retries, backoff, rejection, and load shedding behave as designed | Open | Test results and caller/client behavior | Engineering |
| Dependency failure | Critical dependency failure, delay, and quota exhaustion have been safely simulated or exercised in a controlled environment; fallback and graceful degradation are verified | Open | Failure-injection report | Engineering |
| Recovery | The service returns to a healthy state after a burst, dependency recovery, failover, or restart | Open | Recovery test and timeline | Reliability owner |
| State recovery | Backups, restore, disaster recovery, and recovery targets are tested where the service owns state | Open | Restore and disaster-recovery exercise | Data and reliability owners |
| Security review | Threats, secure-development checks, critical vulnerabilities, and secure defaults have been reviewed for the risk tier | Open | Review and scan results | Security owner |
| Identity and access | People, services, vendors, and emergency users have auditable least-privilege access | Open | Access review | Security and service owners |
| Secrets | Secrets are outside source and build artifacts, rotated, and revocable through a tested path | Open | Secret inventory and rotation test | Security owner |
| Data and privacy | Data, purpose, location, processors, access, retention, deletion, export, and user choices are mapped | Open | Approved data-flow and retention record | Privacy and data owners |
| Sensitive telemetry | Logs, traces, recordings, and support tools minimize or protect sensitive content | Open | Telemetry schema and access/retention review | Security and operations |
| Notices and choices | Required disclosure, consent, opt-out, revocation, deletion, and incident paths work end to end | Open | Scenario tests and legal approval where needed | Legal/privacy and product |
| Automated tests | Critical contracts, policies, business rules, and outcomes have release-blocking tests | Open | Continuous integration (CI) results | Engineering |
| End-to-end tests | Production-like identity, infrastructure, data shapes, and external dependencies have been exercised | Open | End-to-end results | Engineering and QA |
| Release inputs | The candidate's code, configuration, schemas, infrastructure, and AI prompts/models where applicable are identifiable and tied to test evidence | Open | Release manifest and test references | Release owner |
| Progressive release | The launch starts with limited, representative traffic and objective expand/stop criteria | Open | Rollout plan and dashboard | Release owner |
| Rollback | An objective trigger starts a rehearsed rollback or deactivation path to a known-good state, including state/schema compatibility | Open | Rehearsal and plan for in-flight work | Release owner |
| Emergency change | Urgent changes have a bounded approval, deployment, monitoring, and follow-up path | Open | Emergency-change runbook | Incident commander |
| Journey telemetry | A critical journey can be followed across logs, metrics, traces, and final business state | Open | Trace and outcome example | Observability owner |
| Alerts | User-visible symptoms and internal causes are monitored; paging alerts are actionable and tested | Open | Alert test and on-call route | On-call owner |
| Responder access | Dashboards, queries, logs, runbooks, and admin tools are available to responders | Open | Access exercise | On-call owner |
| Incident response | Incident authority, operations, communications, escalation, vendor contacts, and handoffs are documented | Open | Exercise and incident plan | Incident owner |
| Support | Customer support is trained on symptoms, workarounds, escalation, and expected launch changes | Open | Support brief and rehearsal | Support owner |
| Launch watch | Monitoring, outcome sampling, communications, and rollback authority are scheduled for an agreed post-launch window | Open | Launch plan | Release owner |
| Cost | The model covers infrastructure/runtime, vendors, data, support, and failure or retry overhead | Open | Cost forecast and sensitivity analysis | Cost owner |
| Unit economics | A unit-cost driver and cost per successful user or business outcome are tracked | Open | Cost dashboard | Product and finance |
| Commercial terms | Vendor pricing and limits, support and escalation, data-processing terms, and workload assumptions are verified | Open | Contract and vendor register | Vendor owner |
Treat this as a baseline. Add controls for the workload's risk tier, keep the list short enough to use, and update it as the system and its failure modes change (Google SRE).
Run the production readiness review in five steps
1. Set the risk tier and decision owner early
Review hard-to-reverse architecture, data, dependency, and recovery decisions during design. Waiting until the day before launch turns the review into a choice between accepting hidden risk and missing a date.
Name the person who makes the final launch decision. Site reliability engineering (SRE), security, privacy, support, product, finance, and vendors can validate evidence, but unclear authority creates delay exactly when the team needs a fast stop or rollback.
2. Let each owner prefill evidence
The service team owns readiness. Ask each named owner to complete their rows before the review, link evidence, and flag blockers. The meeting should not be the first time anyone sees missing capacity data or an untested restore path.
3. Review blockers and failure paths
Spend review time on the critical user journey, biggest dependency, highest-impact action, recovery path, and remaining uncertainty. Do not read every green row aloud.
For each failure, ask five questions:
- What does the user experience?
- How do we detect it?
- What contains the blast radius?
- Who can act, and with which runbook and access?
- How do we prove recovery?
4. Record one decision
Use one of three outcomes:
- Go: All blockers passed and the release can follow the approved plan.
- Limited go: The team narrows tenants, geography, channel, traffic, or allowed actions while it gathers evidence.
- No-go: A blocker remains or the residual risk exceeds the decision owner's authority.
Attach any approved, time-limited exception to that decision with its mitigation, owner, approver, and expiration. Record objective stop and rollback triggers with the person authorized to act. A limited go narrows exposure; it does not silently waive a blocker.
5. Verify after real traffic
Monitor the agreed launch window, sample user outcomes, test support escalation, and compare cost and capacity with the forecast. Expand, hold, or roll back using the same approval criteria. Log deviations as follow-up work.
Worked example: a production voice-agent launch
Consider an inbound appointment-scheduling agent. It checks availability, creates a booking, sends a confirmation, and can transfer the caller to a person. The critical outcome is a valid booking and confirmation or a completed human handoff, without duplicate or lost side effects. The review must validate that result across the media path, agent, business tools, telephony, privacy controls, and human fallback; testing each component separately is not enough.
Here is a completed decision record for the hypothetical launch. Its targets belong to this workload; they are not defaults for every voice agent.
| Gate | Scenario-specific pass criterion | Evidence | Owner | Final status |
|---|---|---|---|---|
| Scope and ownership | One tenant, one inbound appointment flow, staffed launch hours, and named business, technical, on-call, privacy, support, cost, and decision owners | Approved scope and ownership record | Engineering lead | Pass |
| Traffic and concurrency | Forecast, burst, long-call, queue, rejection, and recovery behavior stay inside the tenant's approved capacity limits | Capacity model and load-test report | Capacity owner | Pass |
| Telephony, media, and latency | Real carrier calls meet the team's caller-audible timing and interruption targets across chosen codecs, noise cases, and failure paths | End-to-end distributions and SIP/media test results | Voice engineer | Pass |
| Tools and final state | Availability reads, booking writes, confirmation, timeout reconciliation, and duplicate protection produce the correct final records | Scenario results and system-of-record audit | Application owner | Pass |
| Observability | One call identifier connects caller outcome, agent/tool events, timing, telephony evidence, and final booking state; tested alerts reach on-call | Trace, dashboard, alert exercise, and runbook | Observability owner | Pass |
| Privacy and data | AI disclosure and recording choice are approved for the use case; access, retention, deletion, and recording-disabled behavior are tested | Legal/privacy approval and scenario tests | Privacy owner | Pass |
| Handoff and support | Caller-requested and policy-triggered transfers finish with a person or a callback/ticket fallback; support can see and escalate the incident | Transfer tests, support rehearsal, and escalation plan | Support owner | Pass after re-test |
| Release and rollback | The full voice configuration has a known-good bundle, limited cohort, stop criteria, practiced disable/rollback path, and active-call plan | Release manifest and rollback rehearsal | Release owner | Pass after re-test |
| Cost and vendor terms | Runtime, carrier, model, storage/export, retries, and transfers are forecast; pricing, capacity, and support terms are confirmed | Cost model and vendor record | Cost owner | Time-limited exception for automated cost alert |
The first review returned no-go because a failed human transfer dropped the caller and the rollback path had not been rehearsed. After the team added a callback fallback, passed the transfer re-test, and rehearsed the known-good configuration, the decision changed to limited go for one tenant during staffed hours. The non-blocking cost-alert exception has an owner and expiration date. Expansion still depends on the same outcome, capacity, latency, transfer, privacy, and cost gates.
Map the complete caller path
Map the carrier and Session Initiation Protocol (SIP) route, media and codec layer, speech recognition, turn detection, agent runtime and model, business tools, speech synthesis, scheduling system, confirmation provider, and human transfer. Add the data recorded or exported at each step and the owner of every dependency.
Propagate one call or turn identifier across the path where the systems support it. A transcript without the corresponding tool result and final booking record cannot prove the task succeeded.
Prove traffic and concurrency behavior
Under steady-state conditions, average concurrent calls can be estimated as the arrival rate multiplied by average call duration. That average is only a starting point. Size and test bursts, long-tail call duration, retries, launch spikes, and uneven tenant or campaign traffic.
Separate these limits:
- call attempts per second;
- established concurrent calls;
- carrier or trunk channels;
- speech, model, runtime, and tool capacity;
- queue depth and wait time; and
- recovery after a burst.
SIP signaling overload and trunk exhaustion are different failure modes; retransmissions can amplify signaling overload. For each limit, define what the caller hears, what the business system records, and whether the call retries, queues, transfers, or stops.
Measure the conversation the caller hears
Set service-specific pass criteria for end-to-end response time, interruption handling, and recovery. Test them across real carrier and browser routes, devices, noise, silence, double-talk, and long calls. Use packet loss, jitter, and component timings to diagnose failures, but make the launch decision from the caller experience and final task outcome.
Verify tools and final business state
For each side-effecting tool, verify selection, authorization, arguments, timeout behavior, reconciliation, and the final system-of-record change. For bookings, payments, messages, customer-record changes, and other side effects, use an idempotency key where the downstream system supports one, and always provide a reconciliation or status lookup. After an ambiguous timeout, check the final state before retrying or telling the caller the action succeeded (HTTP semantics).
Test privacy and human fallback as real flows
Evaluate these as separate legal and policy questions:
- disclosure that the caller is interacting with AI where required;
- consent or other lawful authority to record a call, where required;
- a lawful basis and policy for processing and retaining audio, transcripts, prompts, tool data, and logs; and
- any additional rules that may apply when deriving a biometric voiceprint; and
- for outbound calls, dialing consent, identification, opt-out, revocation, and do-not-call controls where required.
The exact duties depend on jurisdiction, call direction and purpose, data, and organizational role. US federal rules can impose prior-consent, identification, opt-out, do-not-call, and recordkeeping duties on different categories of covered artificial or prerecorded voice calls. The Federal Communications Commission has confirmed that AI-generated human voices fall within the Telephone Consumer Protection Act's artificial/prerecorded-voice provision (FCC 24-17). Use legal counsel to set the criteria, then test the applicable disclosure, consent evidence, opt-out or revocation, recording-disabled path, retention, deletion, support access, and incident export.
A human-handoff test passes only when the person connects or a defined fallback completes. Accepting a SIP transfer request is not the final outcome. Test busy, reject, timeout, after-hours, no-agent, context delivery, caller recovery, and creation of a callback or ticket when transfer fails.
Release a reversible voice configuration
Treat the prompt or dialogue policy, model/provider, endpointing, voice, tool schemas, telephony routing, and compliance messages as one release bundle. A code-only rollback can leave incompatible configuration or side effects behind.
Start with a small but representative cohort. Compare task success, tool correctness, end-to-end latency, interruption recovery, media/SIP failures, transfer completion, abandonment, and cost against the control and absolute launch limits (Google SRE canary guidance).
Keep a known-good bundle, an emergency stop, an authorized rollback owner, and a plan for active calls and already-started actions. Our production pilot framework provides a deeper way to compare platforms against the same outcome and reliability gates.
Apply the checklist in Dasha
With Dasha, you can test a disabled agent through browser voice or chat, place a real phone call, test webhook payloads, verify an MCP connection, and inspect a completed call before enabling production traffic. Our production checklist documents the manual launch workflow.
For completed calls, our Call Inspector can show the transcript, optional audio, model and tool details, event timeline, and speech recognition, model, and synthesis latency breakdown. Additional launch evidence can come from call history, activity logs, concurrency monitoring, the call-queue API, and call-level SIP traces.
A disabled clone can support manual pre-production comparison, while the production checklist documents disabling the agent as the emergency stop procedure. The documented workflow is manual; it does not replace your version history, environments, traffic splitting, canaries, regression gates, or rollback process. Use these surfaces inside your own go/no-go process. You remain responsible for acceptance criteria, downstream systems, telephony configuration, privacy and compliance decisions, human escalation, release controls, protection of recordings and sensitive call data, and launch approval.
Keep readiness current after launch
Production readiness decays. Re-run material gates after major changes to traffic, dependencies, models or prompts, schemas, telephony, data policy, vendor contracts, architecture, or ownership. Convert incidents and near misses into tests, alerts, runbooks, capacity scenarios, or checklist revisions.
Automate objective evidence in continuous integration, deployment pipelines, and service tooling. Keep human approval for residual risk, exceptions, and user-impact tradeoffs. Review expiring exceptions and stale evidence on an agreed cadence.
For a voice workload, track runtime, carrier, model, storage/export, retry, transfer, and support costs separately. Measure cost per successful outcome rather than a base rate alone.
If you are building a production voice agent, use this checklist on your current stack, then evaluate Dasha against the same gates. See how our managed voice AI platform works.