Production Readiness Checklist for a Cloud-Deployed Web App

Overview

Production readiness is a risk review, not a single test. A web app can work correctly in a development environment and still fail in production because of an exposed secret, an untested migration, an incomplete backup, a missing alert, or a deployment process that cannot be reversed.

Start by defining what “ready” means for this release. Record the application version, planned deployment window, responsible owner, affected services, expected user impact, and rollback decision-maker. This simple release record gives the team a shared reference when several components—such as a frontend, API, database, authentication provider, storage service, and hosting platform—are involved.

Your checklist should also reflect the architecture you actually operate. A low-code app builder, a backend as a service, a serverless API, and a containerized application have different control surfaces. Review provider settings, deployment logs, environment variables, database controls, domains, and observability features rather than assuming that a platform’s defaults cover every requirement. For broader architecture context, see Modern App Stack Architecture and the guide to building and deploying a full-stack web app in the cloud.

What to track

Environment separation and configuration

• Confirm development, staging, and production environments are clearly separated.
• Verify that production uses production-only databases, storage buckets, queues, domains, and third-party credentials.
• Document which configuration values are required at build time and which are read at runtime.
• Check that staging resembles production closely enough to reveal configuration, routing, permission, and migration problems.
• Test the deployment with the exact build command and configuration used by the production pipeline.

Keep secrets out of source control, client-side bundles, screenshots, and ordinary logs. Store them in the hosting platform’s secret manager or an equivalent protected system, restrict access by role, and rotate credentials when exposure is suspected or team access changes. Maintain a list of secrets and their owners without recording the secret values themselves.

Authentication and authorization

• Test sign-up, sign-in, sign-out, password recovery, session expiry, and account verification where applicable.
• Confirm protected pages and API routes reject unauthenticated requests.
• Test authorization separately from authentication: a signed-in user should not automatically access another user’s records or administrative functions.
• Review cookie settings, token handling, redirect behavior, and error messages.
• Check administrative accounts, service accounts, and emergency access procedures.

Use representative roles and negative tests. For example, attempt to access a record by changing its identifier, call an administrative endpoint as a normal user, and submit expired or malformed credentials. If you use a backend as a service, inspect both provider-level rules and application-level checks; one layer should not be treated as a substitute for the other.

Database, storage, and migrations

• Confirm backups are enabled, retained according to your requirements, and accessible to the people responsible for recovery.
• Perform a restore test in a non-production environment and record how long the process takes.
• Review the migration order, compatibility between application versions, indexes, constraints, and seed data.
• Know whether a migration is reversible. If it is not, prepare a forward recovery plan before release.
• Verify file storage permissions, upload limits, content handling, and lifecycle rules.

Do not regard a successful migration command as proof that recovery is possible. A useful database readiness record includes the backup location, restore owner, last restore test, expected recovery point, and expected recovery time. Include queues, object storage, search indexes, and other stateful services in the review when they are part of the application.

Error handling, logging, and monitoring

• Show users clear, safe error messages without exposing stack traces, credentials, queries, or internal identifiers.
• Send application errors and failed background jobs to a monitored destination.
• Include enough context to investigate a request, such as a timestamp, route, deployment version, and correlation identifier.
• Redact tokens, passwords, personal data, and sensitive request bodies from logs.
• Set alerts for the failures that require action, not every harmless warning.

Define a small operational baseline: request failure rate, latency for important routes, background job failures, database health, resource usage, and availability of critical dependencies. Add a health check that tests meaningful dependencies where appropriate, but avoid making a broad dependency outage harder to diagnose by hiding the distinction between application failure and provider failure.

Performance, accessibility, and user experience

• Test the highest-value user journeys on representative devices and network conditions.
• Check page loading, API response time, asset sizes, image handling, caching, and database query behavior.
• Confirm loading, empty, validation, permission, offline, and failure states are usable.
• Navigate key flows with a keyboard, inspect focus visibility, test form labels, and review color contrast.
• Check responsive layouts, readable text, meaningful headings, alternative text, and accessible error messages.

Performance work should follow user journeys rather than a single score. Identify the slowest important operation, establish a baseline, and record whether a change improves or worsens it. A lightweight application stack may not need complex optimization, but it does need predictable behavior under its expected workload.

Security and deployment controls

• Use HTTPS for production traffic and confirm redirects and canonical domains behave correctly.
• Review security headers, cross-origin rules, content security settings, cookie attributes, and request protections for your framework and deployment model.
• Remove debug modes, test accounts, sample credentials, unused routes, and temporary administrative endpoints.
• Scan dependencies and review high-risk changes before release.
• Restrict deployment permissions and protect the production branch or equivalent release path.
• Confirm domain, DNS, certificate, webhook, email, and third-party integration settings.

Security settings vary by framework and provider, so verify behavior in the deployed environment instead of copying a generic configuration. A deployment checklist should also state who can approve production releases and how an urgent fix is reviewed when the normal process cannot be followed.

Cadence and checkpoints

Use the checklist at several levels rather than waiting for a major launch.

• Every release: verify the build, environment, migration plan, critical user journeys, monitoring, and rollback path.
• Before an initial launch: complete the full review, including backups, restore testing, permissions, accessibility, security controls, domains, and support ownership.
• Monthly: review alerts, failed jobs, error trends, dependency updates, secret ownership, access permissions, and cloud resource usage.
• Quarterly: test a restore, review recovery objectives, inspect slow or expensive operations, remove unused infrastructure, and run a deeper authorization and accessibility review.
• After an incident: update the checklist with the missing control, add a test that would detect the problem, and assign an owner and due date.

Keep evidence with the release record: test results, migration output, backup or restore notes, monitoring links, approval details, and known limitations. This avoids repeating the same investigation and makes handoffs easier. If your architecture or platform changes, update the checklist immediately rather than waiting for the next calendar review. Platform comparisons such as Firebase, Supabase, and Appwrite can help frame trade-offs, but the final checklist must match the services you operate.

How to interpret changes

Not every change requires delaying a release, but every change should have an explicit owner and decision. Classify findings as blocking, urgent, scheduled, or informational.

• Blockers: exposed secrets, broken authentication, missing data recovery, destructive migrations without a recovery plan, or a deployment that cannot be reversed.
• Urgent issues: unmonitored critical paths, serious authorization gaps, repeated errors, or a major performance regression.
• Scheduled work: improvements that do not create immediate unacceptable risk but need a deadline, such as reducing an avoidable query cost or expanding test coverage.
• Informational findings: documented limitations, minor warnings, or follow-up ideas that do not affect the release decision.

Look for trends, not isolated numbers. A gradual increase in latency, recurring failed jobs, growing log volume, or more frequent manual interventions can indicate that the current design is approaching its limits. Compare results with the previous release and investigate changes in traffic, code, data volume, provider configuration, and dependencies before choosing a remedy.

When to revisit

Revisit this production readiness checklist before every launch, major feature release, database change, authentication change, domain migration, infrastructure change, or provider change. Also schedule a monthly operational review and a deeper quarterly review, even when the application appears stable.

Refresh the document after an incident, failed deployment, security finding, restore exercise, or significant change to the modern app stack. Provider dashboards, deployment settings, authentication capabilities, and database controls can change over time, so verify the instructions against the current configuration rather than assuming an old checklist remains accurate.

To make the next review practical, finish this one with three records:

1. A release decision stating whether the app is ready, ready with accepted risks, or not ready.
2. An action list with owners, deadlines, severity, and links to evidence.
3. A next-review date tied to the next release or recurring operational checkpoint.

Store the checklist where the development and operations teams can update it, and keep a dated copy for each important release. A dependable cloud deployment workflow is not defined by a perfect launch; it is defined by repeatable checks, visible risks, recoverable failures, and steady improvement.