What Happens When Your Only "DevOps Person" Quits?

It’s 4pm on a Friday when the Slack message arrives: “Hey, do you have a minute?”

Everyone in tech knows that feeling. You open the message hoping it’s about a project update. It isn’t.

Your only DevOps person, the one who knows how every system works, who set up the AWS account three years ago, who knows why that one cron job runs at 3am and what breaks if it doesn’t — they’re giving notice.

This article is what happens next. Not the prevention advice you should have read six months ago. The honest breakdown of what’s at risk right now, what will break first, and what your actual options are when your DevOps person quits.

The First Problem: You Don’t Know What You Don’t Know

Most small companies have the same invisible problem: one person holds all the context.

Not just “the passwords.” The full picture — which EC2 instances are production versus test, why the load balancer is configured the way it is, what that Lambda function actually does, which vendors bill monthly and which ones require manual renewal, how to roll back a bad deployment, who to call when AWS support is needed.

None of that is written down. It lived in one person’s head.

This is what the SRE community calls a bus factor of 1: if that one person gets hit by a bus (or gives two weeks’ notice), everything they know disappears with them. It’s one of the most common findings we see at small companies, and almost nobody fixes it until it’s already a crisis.

We had a client whose only ops person left with two weeks’ notice. Three weeks after they walked out, an auto-scaling group started launching EC2 instances nobody recognized. Turns out they’d been running for six months, a test environment quietly billing $800/month.

Nobody knew what it did, whether it was safe to terminate, or why it existed. The Slack message asking about it went unanswered.

That’s what the infrastructure black box feels like.

Want someone to map out what’s actually in your infrastructure before you’re in this situation? Request a free async audit — we’ll document what you have and tell you what’s worth worrying about. No call required.

What Actually Breaks (And When)

The Notice Period Window

This is the most important two weeks you have, and most companies waste it.

When someone gives notice, the natural instinct is to focus on transition meetings, project handoffs, and replacing them quickly. Those matter. But the infrastructure handoff is what you’ll feel six months from now.

During their notice period, extract these things specifically:

• All credentials and access: AWS root account, DNS registrar, GitHub org owner, any SaaS tools they were the primary admin for. Don’t assume IT has these — in a small company, they often don’t.
• Architecture documentation: Even a rough diagram of what systems exist and how they connect is better than nothing. An hour with Excalidraw or a Google Doc is enough.
• Runbooks for common incidents: What do you do if the main database goes down? If SSL renewal fails? If a deployment breaks? If they’ve been handling these alone, write it down now.
• On-call contacts and vendor relationships: Who is your AWS account manager? Who handles the domain registrar? Which support contracts does the company have?

Most ops engineers are willing to help with this if you ask clearly. The problem is that companies don’t ask clearly, and the two weeks evaporates in going-away lunches and status meetings.

Month One

The first month after they’re gone is when it gets real.

The first production incident hits. Something breaks — a certificate expires, a service crashes, a deployment fails — and nobody knows what to do. The developers who were just writing code are now staring at Terraform state files or AWS CloudWatch logs they’ve never touched.

Deployments slow down or stop entirely. Not because the code isn’t ready, but because nobody has the confidence or credentials to push to production. One week without shipping becomes two weeks, then a month.

The AWS bill arrives and nobody can explain it. The person who understood what every line item meant is gone. You’re now paying for things you might not need, and you don’t know which ones matter.

The Recovery Timeline Nobody Tells You About

Here’s the math nobody puts in writing.

Finding a DevOps engineer takes 45-90 days to get to an offer, assuming you find the right person quickly. Add two weeks for them to give notice at their current job. Then plan for three to six months before they’re fully productive — they need to understand your systems, your stack, your history, and the decisions that were made before they arrived.

That’s five to eight months from resignation to someone who can operate your infrastructure confidently. In the best case. If hiring takes longer (and for senior ops roles, it usually does), you’re looking at close to a year.

Meanwhile, the salary for a competent DevOps engineer is $120K-$180K depending on your market, plus benefits, plus the recruiting cost if you’re using a placement firm, which runs 15-25% of first-year salary. You’re looking at $150K-$220K all-in to get someone in the seat.

If that math makes you pause, you’re not alone.

Your 3 Options After a DevOps Departure

You have three realistic paths. Each one has real trade-offs.

Option 1 — Hire Fast

This is the right answer if your infrastructure is genuinely complex, your team is scaling quickly, or you have serious compliance requirements. You need someone full-time, and fractional or consulting coverage won’t be enough long-term.

The honest downside: you’re committing significant budget before you know whether the role justifies it, and the five-to-eight month timeline to full productivity means you’re carrying the gap regardless.

Before you default to this option, it’s worth reading whether you actually need a full-time DevOps hire. The answer depends on how much ops work your team actually needs, not on how much is piling up during the transition.

Option 2 — Absorb It

This is the path of least resistance, and it’s almost always more expensive than it looks.

Your developers start handling deployments. They pick up the on-call rotation. Someone figures out how to restart the service when it crashes. It works, in the sense that nothing falls over permanently.

What actually happens: your developers stop shipping features. Every hour spent on infrastructure is an hour not spent building product. The engineers who were hired to build things are now doing ops on the side, they resent it, and eventually some of them start sending their own “hey, do you have a minute?” Slack messages.

Absorbing it isn’t free. It’s just a cost that doesn’t show up on an invoice.

Option 3 — Bridge with Fractional DevOps

This is what we’d recommend for most small companies facing an ops departure: bring in fractional DevOps coverage immediately to stabilize the environment, then use that time to figure out whether you actually need a full-time hire.

The fractional model gives you senior ops expertise without the ramp time. There’s no six-month onboarding period — a good fractional DevOps partner can come in, assess your infrastructure, document what exists, and handle incidents within the first week.

We had a client, a 20-person SaaS company, who brought us in when their only ops person left. We spent the first two weeks documenting their entire AWS environment, cleaning up unused resources, and writing runbooks for their three most common incidents.

By the end of month one, their developers could handle routine deployments on their own. The client realized they needed 10-15 hours of ongoing ops support per month, not a $180K hire. That’s the fractional model working as intended.

To understand what this actually looks like in practice, see how fractional DevOps works for small teams.

The Deeper Problem This Just Exposed

Here’s the uncomfortable part.

Your DevOps person quitting isn’t the real problem. It’s the event that revealed you had a bus factor of 1, that your infrastructure was entirely dependent on a single person who could leave at any time. That’s always been the risk. Today’s the day it became visible.

The good news is this problem is fixable. Infrastructure as Code (IaC) with Terraform or Pulumi means your environment is defined in code, not in one person’s memory. Documented runbooks mean incidents don’t require tribal knowledge. Shared credential management in something like 1Password or AWS Secrets Manager means credentials don’t disappear when someone does.

If you want somewhere to start, here are five DevOps quick wins any developer can implement today, including a few that specifically reduce your key-person risk.

What to Do Right Now

The notice period is your window. Don’t spend it on going-away events.

Get the credentials. Get the architecture documentation. Get runbooks for anything critical. Even rough notes are better than nothing.

If you’re already past that window and your ops person is gone, don’t try to reconstruct it all from scratch using developers who have products to ship. Bring in someone who can assess what exists and stabilize it fast.

If you’re in this situation right now — or trying to avoid it — request a free async audit. We’ll look at your infrastructure, document what we find, and give you a clear picture of your exposure. You’ll get a Loom walkthrough and a written report. No call required.

The resignation doesn’t have to be a disaster. But the two weeks after it lands are the ones that matter most.