The most dangerous sentence in a go-live meeting is usually some variation of: “It worked in QA.”
Passing QA confirms that tested features work under the test conditions. Before launch, also review production traffic, quotas, permissions, failure handling, costs, and operational ownership.
This checklist is designed for that gap. It does not assume every workload uses every Google Cloud product. Instead, it asks the questions that tend to expose weak spots before a launch: who owns this, how does it fail, what can it access, what happens when traffic doubles, how do we know users are hurting, and can we recover without improvising?
Ready
Evidence exists. The control has been tested.
Evidence exists. The control has been tested.
Needs Action
A gap exists. Give it an owner and a date.
A gap exists. Give it an owner and a date.
Not Applicable
Record why the check does not apply.
Record why the check does not apply.
How to use it
Do not try to make every box green by argument. Mark each check Ready, Needs Action, or Not Applicable. For anything not ready, assign an owner and a date. A production-readiness review is valuable because it exposes risk—not because it produces a perfect score.
Navigate the review
Review 50 Checks Across Ten Areas
This is a long checklist by design. Use the links below to jump straight to the part owned by your team, then return to the readiness gate before go-live.
01 · Foundation
02 · Identity
03 · Networking
04 · Security
05 · Application
06 · Runtime Platform
07 · Delivery
08 · Operability
09 · Reliability
10 · Go-Live
02 · Identity
03 · Networking
04 · Security
05 · Application
06 · Runtime Platform
07 · Delivery
08 · Operability
09 · Reliability
10 · Go-Live
Scope note
This 50-point list is a practical go-live readiness review, not a full Well-Architected assessment. Use the deeper Google Cloud framework for organization-specific topics such as sustainability, regulatory requirements, AI/ML perspectives, or service-specific architecture reviews.
01 · Foundation
Project, Environment & Ownership
Before checking CPU limits or dashboards, make sure the production environment itself is deliberate. A surprising number of go-live problems begin with a project boundary, policy, ownership, or dependency nobody formally decided.
01
Is the production project structure final?
Production should not be a renamed sandbox. Confirm the organization, folders, projects, billing attachment, regions, and environment boundaries before traffic arrives.
Ready when: teams know exactly which projects are production and why each one exists.
02
Is every production resource owned by someone?
A resource without an owner is eventually an incident, a cost leak, or both. Establish accountable application, platform, security, and business owners.
Ready when: an engineer can name the owner of every critical workload and shared service.
03
Are required APIs enabled deliberately?
Do not discover during go-live that a service API was never enabled—or that a broad bootstrap process enabled far more than the workload needs.
Ready when: the enabled API set is understood, documented, and reproducible.
04
Are organization policies understood?
Constraints around external IPs, resource locations, service accounts, networks, or allowed services can break a deployment that worked perfectly in a looser project.
Ready when: the production design has been tested against the real organization-policy inheritance.
05
Have you documented the architecture people will actually operate?
The diagram used in a design review is only useful if it resembles the deployed system. Capture dependencies, trust boundaries, data flows, regions, and failure paths.
Ready when: the on-call engineer can use the architecture diagram during an incident.
02 · Identity
IAM & Workload Identity
Production access should be explainable. The important question is not simply whether something can authenticate, but whether it is using the right identity with the smallest useful permission set.
06
Are human permissions based on least privilege?
Production access should reflect job responsibilities, not convenience. Broad Editor or Owner access is a warning sign, especially when granted directly to individuals.
Ready when: privileged access is minimal, reviewable, and mostly group-based.
07
Are build, deployment, and runtime identities separated?
A CI build does not need the same permissions as the application it produces. Keeping these identities separate reduces blast radius and makes audit trails meaningful.
Ready when: each stage uses its own purpose-built identity.
08
Are long-lived service-account keys avoided?
Static keys are easy to copy, difficult to rotate consistently, and often survive far longer than intended. Prefer federation or platform-provided identities.
Ready when: production workloads do not depend on downloaded JSON keys.
09
For GKE, are workloads using Workload Identity Federation?
Google recommends Workload Identity Federation for GKE when workloads call Google Cloud APIs. Give distinct workloads distinct Kubernetes ServiceAccounts and permissions.
Ready when: pods access Google Cloud APIs without embedded service-account credentials.
10
Is emergency access designed before the emergency?
Break-glass access should be controlled, monitored, and rare. Designing it while production is already failing is a poor time to invent governance.
Ready when: the team knows how emergency elevation works and how it is reviewed afterward.
03 · Networking
Network, DNS & Exposure
Networking tends to look finished right up until DNS, egress, firewall policy, NAT, or a third-party dependency behaves differently under production traffic.
11
Is the VPC and subnet design final?
Confirm address ranges, regional placement, Shared VPC decisions, peering or NCC connectivity, and room for growth. Renumbering after go-live is never the fun option.
Ready when: the network can scale without overlapping ranges or emergency redesign.
12
Are firewall rules intentionally narrow?
Rules that allow broad source ranges, broad protocols, or broad destinations are often created during troubleshooting and quietly survive into production.
Ready when: every permissive rule has a reason, an owner, and a review path.
13
Is internet exposure intentional?
Public IPs, public load balancers, and public service endpoints should be architecture choices—not defaults inherited from a quickstart.
Ready when: the team can explain every internet-reachable endpoint.
14
Are DNS, certificates, and domain ownership production-ready?
A healthy backend is irrelevant if DNS points to the wrong place or a certificate expires unnoticed. Test the full name-resolution and TLS path.
Ready when: production names resolve correctly and certificates have a managed renewal path.
15
Have egress paths been reviewed?
Outbound internet, NAT, proxies, third-party APIs, private service access, and cross-region traffic can affect reliability, security, and cost.
Ready when: critical outbound dependencies are known, permitted, observable, and capacity-tested.
04 · Security
Secrets, Supply Chain & Auditability
Security readiness is not one scanner at the end of CI. It is a chain of choices about credentials, software supply chain, logging, data, identity, and blast radius.
16
Are secrets stored outside source code and manifests?
Credentials, API keys, certificates, and passwords belong in a secrets system such as Secret Manager—not in Git, container images, or environment files committed to the repo.
Ready when: a repository scan reveals no production secrets.
17
Are secret permissions and rotation understood?
Storing a value in Secret Manager is only the first step. Review who can access it, how applications bind to versions, and what happens during rotation.
Ready when: secret access is least-privilege and rotation has been tested.
18
Are container images and dependencies scanned?
A production build should surface known vulnerabilities before deployment. Decide which findings block release and which require documented exceptions.
Ready when: critical findings cannot silently ride into production.
19
Are audit logs and security-relevant logs available?
When access changes or suspicious activity occurs, the team should have evidence. Confirm the logs you rely on are enabled, retained, searchable, and protected.
Ready when: security responders can reconstruct important administrative actions.
20
Has the workload passed an explicit security review?
A security review should cover identity, network exposure, data handling, secrets, supply chain, logging, threat scenarios, and applicable organization policies.
Ready when: the security owner has signed off on known risks and exceptions.
05 · Application
Runtime Behaviour & Dependencies
A production platform can only do so much for an application that does not know how to start, stop, retry, degrade, and expose useful health.
21
Does the application fail safely when a dependency is unavailable?
Databases, APIs, queues, and identity providers will eventually misbehave. Decide whether the service retries, degrades, queues, rejects, or fails fast.
Ready when: dependency failure produces a controlled response rather than a cascade.
22
Are startup and shutdown behaviours tested?
Containers are restarted, rescheduled, and replaced. Applications need predictable startup, graceful termination, connection cleanup, and sensible timeouts.
Ready when: routine restarts do not corrupt work or create avoidable errors.
23
Are health checks meaningful?
A process answering on a port is not automatically healthy. Health signals should reflect whether the application can serve useful traffic.
Ready when: the health endpoint detects conditions users would actually care about.
24
Is configuration separated from the application artifact?
Environment-specific configuration should be changeable without rebuilding source into a different binary or image for every environment.
Ready when: the same release artifact can be promoted with controlled configuration.
25
Have external dependencies and limits been documented?
SaaS APIs, payment providers, identity systems, databases, and rate-limited services are part of your production architecture whether they appear in your repository or not.
Ready when: owners know the dependency, timeout, retry, quota, and escalation behaviour.
06 · Runtime Platform
GKE & Cloud Run Readiness
Managed platforms remove operational work; they do not remove engineering decisions. Requests, probes, concurrency, autoscaling, disruption, and dependency capacity still matter.
26
For GKE, are CPU and memory requests realistic?
Kubernetes schedules on requests. Wildly inflated requests can waste capacity; unrealistically small ones can create contention and instability.
Ready when: requests are based on observed or load-tested behaviour, not guesses copied from another service.
27
Are readiness, liveness, and startup probes configured where appropriate?
Each probe answers a different question. Misusing them can turn a slow dependency into a restart storm or send traffic to an instance that is not ready.
Ready when: probe behaviour has been tested during startup, dependency failure, and recovery.
28
Is autoscaling bounded and tested?
Whether you use GKE autoscaling or Cloud Run autoscaling, verify both scale-out and scale-in behaviour and understand the downstream systems that must absorb the change.
Ready when: traffic growth does not create uncontrolled scale or dependency collapse.
29
For Cloud Run, are min/max instances and concurrency intentional?
Minimum instances trade cost for latency; maximum instances can protect budgets and downstream capacity. Concurrency changes both performance and economics.
Ready when: scaling settings reflect the workload’s latency, cost, and dependency constraints.
30
Is disruption tolerance designed?
Test how replicas and disruption controls handle node maintenance, rolling updates, rescheduling, zone failures, and instance replacement.
Ready when: planned platform disruption does not become user-visible downtime.
07 · Delivery
CI/CD, Artifacts & Rollback
A production deployment should be reproducible, traceable, controlled, and reversible. If the release process depends on somebody’s laptop, it is not finished.
31
Can every production release be traced to source?
You should be able to move from a running version back to the exact commit, build, tests, image, and approval that produced it.
Ready when: a production incident can identify the responsible change in minutes.
32
Are artifacts immutable and promoted rather than rebuilt?
Build once and promote the same artifact through environments. Rebuilding separately for QA and production creates unnecessary uncertainty.
Ready when: the image tested in pre-production is the image that reaches production.
33
Do failed tests and security gates actually stop delivery?
A pipeline that reports failures but still publishes or deploys is a dashboard, not a control.
Ready when: required validation failures make the release ineligible for promotion.
34
Is production promotion controlled?
Whether approval is human, policy-driven, or both, production should have a deliberate gate that is separate from simply merging code.
Ready when: there is a clear, auditable answer to who or what authorized production.
35
Has rollback been rehearsed?
Do not wait for the first bad release to discover that rollback depends on a missing image tag, deleted manifest, or undocumented command.
Ready when: the team has successfully restored a previous known-good release.
08 · Operability
Monitoring, SLOs & Incident Signals
The real test of observability is not whether dashboards exist. It is whether the right person can tell that users are hurting, understand why, and start fixing it quickly.
Official Google Cloud Tech video: Observability in action. A useful visual companion to the checks on user-facing health, dashboards, incident signals, and telemetry correlation.
36
Can you tell within five minutes that the service is failing?
Monitoring being enabled is not the same as monitoring being useful. Alerts should detect user-impacting failure quickly enough to matter.
Ready when: a realistic failure triggers an actionable notification.
37
Do dashboards show user-facing health, not just infrastructure?
CPU and memory are useful, but users experience availability, latency, errors, and successful transactions. Make those visible too.
Ready when: the main dashboard answers “is the service working for users?”
38
Are SLIs and SLOs defined for critical services?
A service-level indicator should track something that correlates with user happiness. An SLO gives the team a reliability target and an error budget to manage.
Ready when: the team can state the service’s reliability objective numerically.
39
Are alerts tied to an owner and a response?
An alert with no owner is noise. An alert with no runbook is a puzzle delivered at the worst possible time.
Ready when: every high-severity alert has a destination, owner, and first-response guidance.
40
Can logs, metrics, traces, and release events be correlated?
Troubleshooting gets much faster when an engineer can connect a spike in errors to a deployment, request trace, dependency, or infrastructure event.
Ready when: the investigation path does not require jumping blindly between disconnected tools.
09 · Reliability
Recovery, Load & Capacity
Failures are not edge cases. They are normal events with different frequencies. Production readiness means deciding in advance which failures you absorb automatically and which require people.
41
Are availability and recovery targets explicit?
Define the service’s availability objective and acceptable recovery point/time. “Highly available” is not a measurable requirement.
Ready when: RTO, RPO, and availability targets are documented and agreed.
42
Are backups configured—and have restores been tested?
A backup is only a theory until a restore works. Verify backup scope, retention, immutability where needed, access control, and recovery procedure.
Ready when: a representative restore has succeeded within the required recovery target.
43
Have zonal or regional failures been considered?
The right answer is workload-specific. Know which components survive a zone failure, which depend on a region, and what manual steps remain.
Ready when: the team knows the expected behaviour during a major locality failure.
44
Has realistic load testing been completed?
Load tests should exercise expected traffic, peaks, scaling transitions, dependency limits, and failure modes—not just produce a pleasing requests-per-second number.
Ready when: the workload meets its latency and error targets at expected and peak load.
45
Are quotas and capacity headroom checked before launch?
Quotas can block scaling and provisioning even when the architecture is correct. Review CPU, IP, API, load-balancer, database, and service-specific quotas before traffic arrives.
Ready when: peak demand fits within quota with sensible headroom, or increases are already approved.
10 · Go-Live
Cost, Runbooks & Operational Ownership
The last five checks are where technical readiness meets operating reality. A system is not ready merely because it can run; somebody has to pay for it, support it, and own the launch decision.
Official Google Cloud Tech video (2026): Before you scale: a guide to Cloud Run cost optimization. It connects max instances, rate limiting, utilization, concurrency, budget protection, and cost controls—the same decisions that matter before go-live.
46
Are budgets and cost alerts configured?
A budget is not a substitute for architecture, but it is an early-warning system. Scope budgets so the people who can act receive the signal.
Ready when: unexpected spend reaches an accountable team before the invoice becomes the first alert.
47
Can cost be attributed to the workload and owner?
Labels, projects, folders, and billing exports are much more useful when they answer who spent the money and for what.
Ready when: teams can explain meaningful production spend by workload or business owner.
48
Is there a runbook for the first likely incidents?
You do not need a 200-page operations manual. Start with the failures you would bet money on seeing first: dependency outage, saturation, bad release, credential issue, and capacity problem.
Ready when: an on-call engineer has a tested first-response path for critical scenarios.
49
Are support, escalation, and on-call responsibilities clear?
Production incidents lose time when nobody knows who owns the application, platform, database, network, or vendor escalation.
Ready when: the escalation path works without relying on tribal knowledge.
50
Has a real go-live review produced a decision?
The final review should not be a ceremonial meeting where every checkbox becomes green by optimism. Record open risks, owners, deadlines, and the actual decision: Go, Conditional Go, or No-Go.
Ready when: unresolved risks are visible and somebody accountable has accepted the launch decision.
Readiness Gate
Turn the checklist into a launch decision
Finish the review with a documented launch decision, named owners for unresolved items, and clear conditions for approval.
GO
Critical controls are ready, known risks are accepted, owners are identified, and rollback/recovery paths have been exercised.
CONDITIONAL GO
Open items exist, but they are understood, bounded, owned, dated, and explicitly accepted by the accountable decision-maker.
NO-GO
A critical security, reliability, recovery, capacity, compliance, or operational gap could create unacceptable impact and has no credible mitigation.
One rule I would not compromise on
Do not turn a No-Go into a Go by changing the wording of the risk. Fix it, mitigate it, or consciously accept it at the right level. Production has an inconvenient habit of eventually testing every assumption you chose not to test yourself.
At a Glance
The 50 checks in one view
Use this condensed list during the meeting, and refer back to the detailed explanations when a check needs discussion.
01Is the production project structure final?
02Is every production resource owned by someone?
03Are required APIs enabled deliberately?
04Are organization policies understood?
05Have you documented the architecture people will actually operate?
06Are human permissions based on least privilege?
07Are build, deployment, and runtime identities separated?
08Are long-lived service-account keys avoided?
09For GKE, are workloads using Workload Identity Federation?
10Is emergency access designed before the emergency?
11Is the VPC and subnet design final?
12Are firewall rules intentionally narrow?
13Is internet exposure intentional?
14Are DNS, certificates, and domain ownership production-ready?
15Have egress paths been reviewed?
16Are secrets stored outside source code and manifests?
17Are secret permissions and rotation understood?
18Are container images and dependencies scanned?
19Are audit logs and security-relevant logs available?
20Has the workload passed an explicit security review?
21Does the application fail safely when a dependency is unavailable?
22Are startup and shutdown behaviours tested?
23Are health checks meaningful?
24Is configuration separated from the application artifact?
25Have external dependencies and limits been documented?
26For GKE, are CPU and memory requests realistic?
27Are readiness, liveness, and startup probes configured where appropriate?
28Is autoscaling bounded and tested?
29For Cloud Run, are min/max instances and concurrency intentional?
30Is disruption tolerance designed?
31Can every production release be traced to source?
32Are artifacts immutable and promoted rather than rebuilt?
33Do failed tests and security gates actually stop delivery?
34Is production promotion controlled?
35Has rollback been rehearsed?
36Can you tell within five minutes that the service is failing?
37Do dashboards show user-facing health, not just infrastructure?
38Are SLIs and SLOs defined for critical services?
39Are alerts tied to an owner and a response?
40Can logs, metrics, traces, and release events be correlated?
41Are availability and recovery targets explicit?
42Are backups configured—and have restores been tested?
43Have zonal or regional failures been considered?
44Has realistic load testing been completed?
45Are quotas and capacity headroom checked before launch?
46Are budgets and cost alerts configured?
47Can cost be attributed to the workload and owner?
48Is there a runbook for the first likely incidents?
49Are support, escalation, and on-call responsibilities clear?
50Has a real go-live review produced a decision?
Final Takeaway
Plan How to Detect and Recover From Failures
Things will fail. A dependency will slow down. A node will disappear. A bad release will slip through. A quota will be closer than expected. Somebody will rotate a credential on the wrong day.
The goal of a good readiness review is not to pretend those events can be eliminated. It is to make sure the system—and the team operating it—has a sensible response when they happen.
If your review only asks “Does it work?”, you are checking functionality. Production readiness asks harder questions: How does it fail? How do we know? Who responds? How do we recover? What does it cost? And which risks are we knowingly carrying into launch?
That is a much better conversation to have on Friday afternoon than Monday morning after go-live.
Official References
Keep the checklist current
Google Cloud services and best practices evolve. These are the core official references I would keep close when turning this checklist into an organization-specific standard.
- Google Cloud Well-Architected Framework
- Google Cloud recommended security checklist
- GKE cluster security hardening guidance
- Workload Identity Federation for GKE
- Cloud Monitoring SLO monitoring
- Cloud Quotas
- Cloud Billing budgets
- Cost anomaly management
- Secret Manager best practices
- Backup and DR overview
Freshness note
This checklist was reviewed against current Google Cloud guidance on September 4, 2026. Adapt it to your organization’s architecture, regulatory requirements, change-management process, and support model rather than treating it as a universal compliance standard.
Going live on Google Cloud?
Use the checklist as a review agenda. Mark the gaps, assign owners, test the recovery paths, and make the launch decision with evidence rather than optimism.
