Most startup outages are not exotic. They come from missing basics: an alert nobody set up, a deploy that could not be rolled back, a backup nobody ever restored, a secret sitting in a repository. These are cheap to fix before a launch and expensive to fix during one.
This production readiness checklist is written for SaaS founders, CTOs and small engineering teams. Use it before your first paying customers, before a big launch or enterprise deal, and again every quarter.
What is a production readiness checklist?
A production readiness checklist is a set of checks that confirm a service can run reliably, securely and recoverably in front of real customers before it goes live or scales up.
It covers more than code quality. It asks whether you can see problems, respond to them, roll back a bad release, recover from data loss and protect customer data. A system that passes these checks is not perfect, but it fails in ways your team can handle.
When should a SaaS startup run one?
Run a production readiness review at four moments: before your first paying customers, before a major launch or enterprise contract, after a significant architecture change, and on a regular schedule such as quarterly.
Enterprise buyers also tend to ask about monitoring, backups, access control and incident response in security questionnaires. Having honest answers ready shortens sales cycles.
What should a production readiness checklist include?
A solid checklist covers ten areas: reliability targets, monitoring and alerting, logging, deployment and rollback, infrastructure as code, container and Kubernetes settings, backups and recovery, security baseline, capacity and cost, and incident response. The sections below explain each one.
1. Reliability targets (SLOs)
Define what "reliable enough" means in numbers before you build alerts.
A Service Level Indicator (SLI) is a measurement, such as the share of requests that succeed. A Service Level Objective (SLO) is the target for it, for example "99.9% of requests succeed over 30 days". An error budget is the amount of failure that target allows. At 99.9%, that is about 43 minutes of full downtime in a 30-day month.
- Pick two or three SLIs that match what customers feel: availability, latency and error rate.
- Set targets you can actually meet. A realistic 99.5% is more useful than an imaginary 99.99%.
- Review the budget monthly. If you keep exhausting it, slow feature work and fix reliability.
2. Monitoring and alerting
You need to know about a problem before your customers tell you.
Start with the four golden signals from Google's Site Reliability Engineering practice: latency, traffic, errors and saturation. Alert on symptoms customers experience, not only on causes such as CPU.
# Prometheus alert example: adapt metric names to your stack
- alert: HighErrorRate
expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05
for: 10m
labels:
severity: page
annotations:
summary: "5xx error rate above 5% for 10 minutes"
runbook: "link to the runbook for this alert"
- Every alert that wakes someone must have a runbook and a clear owner.
- Delete or downgrade alerts that fire often and need no action. Alert fatigue hides real incidents.
- Add an external uptime check that tests a real user journey, not just a health endpoint.
3. Logging and tracing
Logs are how you reconstruct what happened.
- Use structured logs (JSON) with a request or correlation ID that follows a request through every service.
- Set retention deliberately and keep audit-relevant logs longer.
- Never write passwords, tokens or personal data into logs. Check this with a test, not an assumption.
- Add tracing for any request that crosses more than two services.
4. Deployment and rollback
A deploy you cannot undo is a gamble.
- Deploy through an automated CI/CD pipeline with tests, not from a laptop.
- Release gradually where you can: canary releases or a small percentage first, with feature flags to turn off new behaviour.
- Practise rollback until it takes minutes. If it requires a meeting, it is not a rollback plan.
- Make database migrations backward compatible using an expand and contract pattern: add the new column first, deploy code that handles both, then remove the old one later. This keeps an old release working after a migration.
- Protect the pipeline itself. See our guide on securing GitHub Actions workflows.
5. Infrastructure as code and environments
If you cannot rebuild your environment from code, you cannot reliably recover or scale it.
- Define infrastructure with Terraform, CloudFormation or an equivalent, and keep it in version control.
- Keep staging close to production in configuration, even if smaller in size.
- Ban manual console changes, or record and review any you make in an emergency.
6. Containers and Kubernetes settings
If you run on Kubernetes, a few settings prevent common failures.
readinessProbe:
httpGet:
path: /healthz/ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
httpGet:
path: /healthz/live
port: 8080
periodSeconds: 15
failureThreshold: 3
resources:
requests:
cpu: 250m
memory: 256Mi
limits:
memory: 512Mi
- Use readiness probes so traffic only reaches healthy pods, and liveness probes so stuck pods restart.
- Set resource requests and limits so one noisy service cannot starve others.
- Add PodDisruptionBudgets and run at least two replicas of anything customer-facing.
- Review manifests before you apply them, especially AI-generated ones. See our post on Kubernetes security and AI-generated manifests.
7. Backups and recovery
A backup you have never restored is an assumption.
- Set a Recovery Point Objective (how much data you can lose) and a Recovery Time Objective (how long you can be down) for each system.
- Store backups in a separate account or region, with access controls that differ from production.
- Restore from backup on a schedule and time it. Record what failed.
- Decide where you would recover if your cloud region were unavailable. Our guide to cloud disaster recovery in the UAE walks through this.
8. Security baseline
Security is part of readiness, not a separate project for later.
- Enforce multi-factor authentication for all staff and cloud accounts, and use least-privilege roles.
- Keep secrets in a secrets manager, not in code, images or environment files in a repository.
- Scan dependencies and container images in the pipeline, and patch on a defined schedule.
- Review your setup against the OWASP Top 10 and the CIS Benchmarks for your cloud and operating systems.
- Add rate limiting and a web application firewall for public endpoints.
- Turn on audit logging for your cloud account and keep it.
9. Capacity, performance and cost
- Load test the paths that matter, such as sign-up, login and checkout, to find the first bottleneck.
- Check database connection limits, queue depth and autoscaling rules.
- Set cloud budgets and cost alerts. A runaway job can become a bill as damaging as an outage.
10. Incident response and on-call
- Define severity levels and who is called for each.
- Keep an on-call rota, even if the team is only three people, and make sure nobody is the only person who understands production.
- Write short runbooks for the top five failure modes.
- Have a status page or customer communication plan before you need it.
- Run blameless post-incident reviews and track the follow-up actions. Our guide to reducing mean time to remediation and our post on real-time incident coordination go deeper.
How do you score production readiness?
Rate each of the ten areas Red, Amber or Green, and treat every Red as a launch blocker.
- Green: in place and tested in the last quarter.
- Amber: in place but untested, or partly done.
- Red: missing, or nobody owns it.
Fix Reds before a launch, plan Ambers for the next sprint and re-score each quarter. The score matters less than the conversation it forces.
What are the most common production readiness mistakes?
- Alerting only on CPU and memory, not on customer-facing errors.
- Taking backups but never testing a restore.
- One engineer being the only person who can deploy or fix production.
- Staging that looks nothing like production, so tests prove little.
- Database migrations that cannot be rolled back with the code.
- Secrets in repositories or shared chat messages.
- No written plan for who communicates with customers during an incident.
How can T-Mat Global help with production readiness?
T-Mat Global Technologies is a founder-led technology delivery partner from India. We help teams with cloud infrastructure, DevOps, CI/CD, cloud security, vulnerability remediation and production support, including monitoring, incident investigation and ongoing maintenance. Our founder, Sainath Mitalakar, is an AWS Certified DevOps Engineer Professional.
We can review your setup against a checklist like this one, fix the gaps that matter first and then support your systems as you grow. See our services and our guide on choosing a provider in the UAE.
Get a free assessment
Need help securing your CI/CD pipelines or improving production reliability? Contact T-Mat Global to discuss your requirements. Visit t-matglobal.com or email info@t-matglobal.com, and book your free assessment.
Frequently asked questions
What is a production readiness review?
It is a structured check, done before launch and on a regular schedule, that confirms a service can be monitored, deployed, secured and recovered reliably.
How long does a production readiness review take?
For a small SaaS product, a first review usually takes a few days, depending on how many systems you run and how much is documented. Later reviews are faster.
What is an SLO and why does a startup need one?
A Service Level Objective is a measurable reliability target, such as 99.9% of requests succeeding over 30 days. It tells you when to prioritise reliability over new features and gives you something concrete to tell customers.
How often should we test backups?
Test a full restore at least quarterly for critical data, and after any major change to your database or storage setup.
Do early-stage startups really need on-call?
Yes, in a simple form. Even a small team needs to know who responds to a serious alert, how they are reached and what they do first.
What security checks belong in production readiness?
Multi-factor authentication, least-privilege access, a secrets manager, dependency and image scanning, patching, audit logging and rate limiting for public endpoints.
Is Kubernetes required for production readiness?
No. The principles apply to any platform. Kubernetes adds specific settings, such as probes, resource limits and disruption budgets, that you should configure if you use it.
When should a startup get outside help?
When no one on the team owns reliability, when incidents keep repeating or when an enterprise deal needs evidence you do not have. An external assessment is a quick way to see what to fix first.