The Service Nobody Owned Until It Broke

A critical notification service was processing 50,000 messages a day. When it started silently dropping SMS, it took a week for anyone to notice — because the alerts were going to a Slack channel that belonged to a team that no longer existed.

I was two days into a consulting engagement at a mid-size SaaS company when I asked a question that made the room go quiet: "Who owns the notification service?"

The engineering director looked at the VP of Platform. The VP looked at the tech lead. The tech lead said, "I think Growth built that originally?" Someone pulled up the Git history. The last meaningful commit was eleven months old, authored by an engineer who'd left the company in March.

The notification service was handling about 50,000 messages per day — email, SMS, and push notifications for everything from password resets to payment confirmations. It was, by any reasonable definition, critical infrastructure. And nobody was responsible for it.

How a service becomes orphaned

The story was depressingly common. Eighteen months earlier, a "Growth" team of four engineers built the notification service as part of a user engagement initiative. They did a decent job. The service worked, the architecture was reasonable, and it integrated cleanly with Twilio for SMS, SendGrid for email, and Firebase for push.

Then the reorg happened. Growth got split — two engineers moved to a new Retention team, one went to Platform, and the original tech lead left the company. Nobody explicitly transferred ownership of the notification service. It just kept running.

For eleven months, this worked fine. The service was stable enough that nobody needed to touch it. But "stable" and "maintained" are different things. When I dug in, the picture was rough:

• Node 18, which had been EOL for five months
• Dependencies that hadn't been updated in fourteen months, including an AWS SDK version with a known memory leak
• A deployment process that lived in a shell script on a specific Jenkins server — not in the shared CI/CD pipeline the rest of the company used
• Exactly one engineer who knew how to deploy it, and she'd learned by accident six months ago when she needed to patch a logging format
• Alerts routed to #team-growth-alerts, a Slack channel that still existed but had been muted by every current member because it also received alerts from three decommissioned services

The README contained a single line below the title: "TODO: add documentation."

The break

It happened on a Tuesday. Twilio deprecated a minor API version that the notification service was pinned to. SMS delivery started failing silently — the service got back a 400 response, logged it as a warning (not an error), and moved on. No retry, no fallback, no alert escalation.

For six days, roughly 8,000 SMS messages per day simply vanished. Password reset texts, two-factor authentication codes, payment confirmation messages. Customer support tickets started climbing, but nobody connected "I can't log in" reports to a notification delivery failure. Why would they? The dashboards were green.

A support engineer finally made the connection on day seven when a customer explicitly said "I never got the SMS code." She checked the notification service logs, found 48,000 warning-level entries about Twilio 400 responses, and raised the alarm.

The fix itself was straightforward — update the Twilio SDK and adjust the API call. Deploying it was not. The one engineer who knew the deployment process was on vacation in a different timezone. The Jenkins server had been moved to a new subnet two months earlier, and the deploy script's hardcoded IP no longer worked. It took four hours and three engineers to get a one-line dependency bump into production.

What actually helps

After the incident, I helped the team put three things in place. None of them were technically sophisticated, which is sort of the point.

A service catalog. A spreadsheet. Not Backstage, not a custom portal — a Google Sheet with columns for service name, owning team, on-call contact, last deploy date, and a link to the runbook. They filled it in during a single afternoon. Three other services turned out to have ambiguous ownership. Two of those had outdated dependencies too.

Ownership as a mandatory field. Every service had to have an owning team in the catalog. When teams got reorganized, updating service ownership became part of the reorg checklist. This sounds obvious. I've seen maybe two companies out of twenty that actually do it.

Automated staleness detection. A weekly script that checked each service's last deployment date, dependency age, and alert channel activity. If a service hadn't been deployed in 90 days, or its alert channel had zero human responses in 30 days, it flagged the service for review. Not a sophisticated system — a cron job that posted to Slack.

The deeper lesson wasn't about tooling. It was about the assumption that stable means safe. The notification service ran fine for eleven months without anyone touching it. That felt like a success. It was actually a slow accumulation of risk — outdated dependencies, unmonitored alert channels, tribal deployment knowledge — that just hadn't been triggered yet.

Every company I consult with has at least one of these services. Usually more. The uncomfortable question isn't whether you have orphaned services. It's whether you'll find them before or after they break.