A production readiness audit is an independent review of a system before it carries real users, real money or real regulatory exposure. It answers one question honestly: if this went live on Monday, what would break, who would notice, and how long would it take to recover?
Where the single points of failure are, and whether degradation is designed or accidental.
Whether backups exist and whether a restore has ever actually been performed.
Whether you would notice a problem before your customers do, and whether alerts reach someone who can act.
Secret handling, authorisation coverage, and whether standing credentials survive a person leaving.
Teams rarely need to be told that reliability matters. What they need is someone outside the delivery pressure to look at the system without the assumptions the team has been living inside for months.
On this page
- Why an independent review finds things the team cannot
- Self-assessment versus an independent audit
- What we examine
- How the engagement runs
- What you receive
- When to commission one
- Questions to ask of any system before launch
- Production readiness audit questions, answered
Why an independent review finds things the team cannot
The people who built a system are the worst placed to audit it, and that is not a criticism of their skill. They know how it is supposed to work, so they read the code that way. They have normalised the manual step in the deploy, the alert that always fires, the one server nobody reboots. An outside reviewer has no such normalisation, and asks the naive question that turns out to matter.
Self-assessment versus an independent audit
Self-assessment
The production readiness checklist
- Work through the production readiness checklist first if you want to self-assess.
- Green means someone has demonstrated it, not that someone believes it.
- There is no total that means ready to launch, and we do not publish one.
An independent audit
When you want an independent view
- An outside reviewer has no such normalisation, and asks the naive question that turns out to matter.
- We read the code and the infrastructure definitions, interview the engineers who built it, and exercise the system.
- Each finding carries the evidence behind it, so your team can act without re-deriving the problem.
What we examine
Figure 1. The seven areas, grouped under the three questions the audit answers
Caption: each area is placed under the question its own description answers on this page. The three questions are the ones in the opening paragraph; the seven areas are the list under What we examine.
How the engagement runs
- Read the codeWe read the code and the infrastructure definitions.
- Interview the buildersWe interview the engineers who built it.
- Exercise the systemWe exercise the system rather than taking documentation at face value.
- Record what is unverifiedWhere a claim cannot be demonstrated, we record it as unverified rather than assuming it holds. That distinction is the whole value of the exercise.
What you receive
You receive a prioritised findings report. Each finding carries the evidence behind it, so your team can act without re-deriving the problem.
What blocks launch.
What needs an owner and a date.
What is acceptable risk to carry knowingly.
- Findings in priority order
- The evidence behind each finding
- Claims that could not be demonstrated, recorded as unverified
When to commission one
- Before a first production launch, especially where the system handles payments, personal data or safety-relevant decisions.
- Before a significant scale-up, where the load profile is about to change by an order of magnitude.
- After inheriting a system, whether through acquisition, a vendor handover or a team change.
- After an incident, where the goal is finding the class of problem rather than the single cause.
- Ahead of a customer or regulatory due diligence process, where you would rather find the gaps first.
Questions to ask of any system before launch
- What would break? Architecture and failure modes, security posture, and performance under real load.
- Who would notice? Whether you would detect a problem before your customers do, and whether alerts reach someone who can act.
- How long would it take to recover? Whether a restore has ever been performed, and whether you can reverse a bad change quickly under pressure.
- Who is on call? Who owns the service, who is on call, and what happens at 3am on a public holiday.
Production readiness audit questions, answered
What is a production readiness audit?
An independent review of a system before it carries real users, real money or real regulatory exposure. It answers one question honestly: if this went live on Monday, what would break, who would notice, and how long would it take to recover?
What does a production readiness audit examine?
Seven areas: architecture and failure modes, data safety, observability, security posture, performance under real load, release and rollback, and operational ownership.
Is a production readiness audit the same as a software security audit?
No. Security posture is one of the seven areas it examines: secret handling, authorisation coverage across every route, dependency risk, and whether standing credentials survive a person leaving. The other six are architecture and failure modes, data safety, observability, performance under real load, release and rollback, and operational ownership.
What do you receive at the end?
A prioritised findings report: what blocks launch, what needs an owner and a date, and what is acceptable risk to carry knowingly. Each finding carries the evidence behind it.
Can we self-assess first?
Yes. Work through the production readiness checklist first if you want to self-assess. The people who built a system are the worst placed to audit it, which is why an independent review finds things the team cannot.
Related pages
Production readiness checklist
A production readiness checklist covering reliability, backups and restore, observability, security, load testing, rollback and on-call ownership.
From vibe coding to production
You built an app by vibe coding with AI. Here is what it takes to make it secure, scalable, and production-ready, step by step.
Sthenos DevOps consulting streamlines your pipeline, automates deployments and builds a culture of continuous delivery.
Work through the production readiness checklist first if you want to self-assess. When you want an independent view, talk to our engineers.