20 Signs Your Infrastructure Needs a DevOps Audit

This is a diagnostic list, not a scare list. Every sign below is something you can check today without opening a console — you either recognise it or you don’t. The point isn’t to hit zero; healthy startups carry a few of these knowingly. The point is to notice which ones you’ve been carrying unknowingly, because those are the ones that turn into a bad weekend. If you’d rather answer questions than read a list, the free 12-question health check is the interactive version — two minutes, no email, instant score.

Shipping and delivery

These are the signs that show up in your roadmap before they show up in your incident channel. Delivery friction is the cheapest problem to fix and the one teams tolerate longest.

1. Your last production deploy needed a maintenance window. Scheduled downtime for a routine release means your deploy path can’t run two versions at once — usually a schema migration coupled to the code that reads it. It’s fixable without re-architecting; the expand-and-contract pattern handles most cases.

2. Only one or two people can deploy, and nobody deploys on Friday. A deploy that requires a specific human is an undocumented manual step wearing a costume. The Friday taboo is the tell: the team doesn’t trust the rollback path, so they avoid deploying when nobody’s around to hand-fix it.

3. Rolling back means redeploying the previous commit and hoping. That’s not a rollback, it’s a second deploy under pressure — and it doesn’t work at all if the bad release already migrated the database. A real rollback is a tested, boring action with a known blast radius.

4. Green in staging tells you nothing about production. When staging has drifted far enough — different instance sizes, stale data, a service stubbed out six months ago — a passing test there stops carrying information, and everyone quietly starts testing in prod. This usually means environments are hand-maintained rather than generated; ephemeral preview environments solve it by making the environment disposable.

5. Nobody can say how long it takes a merged PR to reach customers. If the answer is a shrug or a range measured in days, there’s no pipeline — there’s a sequence of people remembering to do things.

Reliability and recovery

Reliability problems are invisible until they’re expensive. Each of these is a gap between “we think we’re fine” and “we can demonstrate we’re fine.”

6. Customers tell you you’re down before your monitoring does. Alerting exists but it watches the wrong things — CPU and disk instead of the symptoms users feel, like error rate, latency, and failed checkouts. It usually means alerts were configured once at launch and never revisited.

7. Nobody has restored from a backup this year. An untested backup is a belief, not a capability. Snapshots that were never restored routinely turn out to be missing a database, encrypted with a rotated key, or too slow to be useful inside your actual downtime tolerance.

8. Your incident response is a Slack thread and one person’s memory. With no runbooks, every outage costs full rediscovery time, and the fix depends on whether a specific engineer is awake. It also means each incident teaches the company nothing.

9. You can’t answer “was it slow last Tuesday?” Short log retention and no metrics history make post-incident analysis impossible — you can only ever fix the outage you’re currently in, never the pattern behind it.

Security and access

These carry the widest severity range: some are hygiene, some will fail an enterprise security review and stall a deal that’s already in your pipeline.

10. One person owns the root account. Whether it’s the AWS root user, the GCP Organization owner, or the Azure Global Administrator, a single unrecoverable identity is both a bus-factor risk and an audit finding. It should be locked away with hardware MFA and used essentially never.

11. Someone who left three months ago still has access. Orphaned accounts mean offboarding is manual and someone forgot a step. If you can’t produce a current list of who has production access, you can’t produce it for an auditor either.

12. Production credentials are long-lived static keys. Access keys pasted into CI settings or a .env file never expire and are almost never rotated. Modern equivalents — OIDC federation from your CI provider, workload identity, instance roles — issue short-lived credentials automatically and remove the thing worth stealing.

13. Your database is reachable from the public internet, or you’re not sure. “Not sure” is the same answer as “yes” for risk purposes. This typically indicates infrastructure grown by hand, where a security group was opened during a debugging session and never closed.

14. A security questionnaire from an enterprise buyer would stall the deal. If you can’t answer questions about encryption, logging, access review, and vendor management from existing evidence, compliance work will land on your critical path at the worst possible moment. Most questionnaires are just the SOC 2 control set in prose, so the gap is rarely the certificate — it’s the evidence underneath it.

Cloud cost

Cost signs are the easiest to verify and the easiest to ignore, because the bill arrives after the decisions that caused it.

15. You can’t predict next month’s cloud bill within about 20%. Unpredictable spend means nobody owns the relationship between what you ship and what it costs — so growth and waste look identical on the invoice.

16. Non-production environments run 24/7. Dev, staging, and QA sitting at full size overnight and all weekend is pure waste, and it’s the most reversible line item you have. Its presence usually means nobody has ever reviewed the bill line by line.

17. Nothing is tagged, so no line item has an owner. Without tags there’s no way to attribute spend to a team, environment, or customer, which makes every cost conversation a guess. We keep a plain breakdown of what infrastructure should cost at this stage for comparison.

Knowledge and bus factor

The quietest category, and the one that converts every other sign on this list from “a problem” into “a crisis.”

18. Your infrastructure was built by hand in the cloud console. Click-built infrastructure can’t be reviewed, diffed, reproduced in another region, or rebuilt after a bad day. It also means the current state exists in exactly one place, and it isn’t in your repo.

19. There is one person you can’t let go on holiday. If a single engineer holds the deploy path, the cloud accounts, and the tribal knowledge, your uptime is a function of their calendar. This is the sign most often noticed only after they resign.

20. Your documentation is a Slack search. When onboarding a new engineer to a working local environment takes more than a day, the missing artifact is written knowledge — and every future hire pays that cost again.

How to read your count

Under four signs and you’re in normal territory for a startup this size — pick the two that scare you most and fix them. Four to eight means the pattern is systemic rather than incidental, and the right move is to sequence the fixes rather than firefight them. Nine or more usually means infrastructure grew faster than anyone had time to design it, which is extremely common and entirely recoverable — but not while you’re also shipping features.

Two ways to go deeper. The free health check scores twelve of these questions instantly and tells you which category is weakest. The $1,900 audit is the thorough version: a week of read-only review of your actual AWS, GCP, or Azure setup, ending in a severity-ranked report with fixes and effort estimates — and you can read a full sample report before deciding whether it’s worth it.