Your Catalog Was Not Down. It Was Confidently Wrong. GitHub Built a Circuit Breaker for That and Most Ownership Systems Have Not.

TL;DR: Service catalogs and ownership models fail most dangerously when they provide "confidently wrong" data rather than no data at all. By implementing a "low water mark" circuit breaker—a pattern recently documented by GitHub—engineering teams can prevent stale ownership records from triggering destructive automated actions or misdirecting incident responders. Success is measured by reducing the "redirect rate" of paged incidents, not by increasing catalog coverage percentages.

The lookup is the first task, and it is not investigation

When a high-severity alert fires at 3:00 AM, the first action a responder takes isn't a deep dive into heap dumps or flame graphs. It is a lookup. The dashboard identifies the unhealthy service, and the human immediately asks, "Who owns this?"

According to Jimmy Soh in Observability Applied, the fundamental distinction in incident response is between detection and coordination. Detection answers what needs attention, but a service ownership model answers who can act. If the lookup fails, the investigation stalls. The industry has spent years trying to solve the "empty field" problem, assuming that if we just reach 100% coverage in our service catalog, the coordination problem is solved. We have been solving the wrong half of the equation.

Three states, not two

In the rush to populate a service catalog engineering teams often overlook the qualitative nature of the data they are collecting. An ownership lookup doesn't just have a binary "success" or "failure" state; it has three distinct outcomes:

1. Nothing: An honest failure. The record is empty. The responder knows immediately to escalate via the human network or a general SRE rotation. This costs minutes.
2. Something stale: The entry describes a world that was true six months ago. The responder may or may not notice the decay until they realize the Slack channel they joined has been archived.
3. Something confidently wrong: This is the most dangerous state. The record returns a specific team name that is indistinguishable from a correct one at the point of use. The responder acts on it, pages a team that cannot help, and burns the most expensive minutes of the incident before circling back to square one.

State 3 is objectively worse than state 1. Yet, almost every internal developer portal and ownership dashboard in existence rewards moving from "Nothing" to "Something" without verifying the accuracy of that "Something." We are incentivizing the creation of "confidently wrong" data.

Why ownership data rots faster than anyone budgets for

Ownership data is not static; it is a high-entropy property of a growing organization. Several decay mechanisms ensure that a service ownership model begins to fail the moment it is "completed."

Reorganizations shift boundaries, and departures leave "orphaned" services that no one remembers building. There is also the modeling problem: GitHub discovered that their service-to-repository relationship was many-to-one, meaning repositories without a currently deployed service effectively had no owner at all.

Key Takeaway: A service catalog that is 100% complete but 20% stale is a liability that actively redirects incident responders toward the wrong solutions.

Furthermore, shared infrastructure often has no natural owner, leading to a "tragedy of the commons" where the real operational expert is never the owner of record in the catalog.

What GitHub found when they tried to fix it

To solve these "sharp edges," GitHub moved to a system of durable per-repository ownership. According to Michael Recachinas, Staff Security Engineer at GitHub, the company moved away from ownership inherited from deployed services to a model where ownership was required at the point of repository creation.

The scale of the cleanup was massive: they archived roughly 8,000 unused repositories, ending with approximately 3,000 active and 11,000 archived repositories. However, the most critical lesson came from their failure modes.

GitHub discovered they were robust against a Service Catalog outage, but they had not accounted for the catalog returning stale or corrupted data. In one instance, archiving an unowned repository silently broke a Datadog workflow. More importantly, they realized that if the catalog returned a large batch of corrupted "unowned" statuses, their automation would have mass-archived thousands of repositories with perfectly valid owners.

The low water mark: a circuit breaker on a trusted lookup

GitHub’s solution was to build a "low water mark" circuit breaker. Instead of blindly trusting the catalog, their automation now counts the destructive actions it is about to take. If the number of pending archives exceeds a conservative threshold, the system aborts the entire run and pages a human.

This principle is generalizable. Any system that acts on data it did not produce—whether it’s who owns this service for auto-assigning incidents, alert escalation, access revocation, or cost attribution—needs a confidence check on the volume of action.

If your on-call rotation suddenly tries to page a team that has never been paged for that service before, or if a cleanup job tries to delete 40% of your service entries in one pass, the system should fail open (or stop entirely) rather than executing a confidently wrong command.

Instrumenting the lookup instead of the catalog

If you want to move past the "coverage" trap, you must start measuring the lookup process itself. Coverage percentage is a vanity metric because it cannot distinguish between states 2 and 3. Instead, track these four metrics:

• Lookup Latency: The time from the first alert to the moment a responder has a name they can actually act on. You can recover this from incident chat timestamps.
• Redirect Rate: The direct measure of "confidently wrong" data. How often was the first team paged not the team that ultimately resolved the incident?
• Answer Provenance: When the catalog identifies an owner, when was that last confirmed by a real event—a deploy, a merged PR, or a page acknowledged—rather than a manual metadata update?
• Silent Dependents: Which automation flows read this ownership record? (As GitHub found, you often only find these by breaking them).

This is where the distinction between static catalogs and dynamic investigation becomes clear. The knowledge a responder actually needs—dependencies, recent changes, and system behavior—rarely lives in a metadata field. At Operate, we focus on reading these sources directly and read-only. By deriving context from the system as it currently exists (code, schema, logs) rather than from a record of what it was, the investigation remains grounded in reality. When Operate proposes a fix, it does so through an auditable PR, ensuring that "who owns this" translates directly into "who reviews this."

Common Pitfalls

• Treating "Unreachable" as "Empty": If your service catalog is down, your automation should stop, not assume every service is now unowned.
• Over-reliance on Auto-Discovery: Automated tools can find services, but they struggle to find accountability. An automated entry with no human verification is just a different flavor of state 3.
• Focusing on MTTR only: Mean Time to Recovery is a blunt instrument. Focusing on "Time to First Actionable Page" provides a clearer picture of ownership health.

Sources & further reading

• According to GitHub's engineering blog, the team had to build a circuit breaker to prevent mass-archival of repositories due to corrupted catalog data.
• According to Jimmy Soh at Observability Applied, the primary task of coordination is often hindered by the lack of documented ownership.
• According to discussions on ExperiencedDevs, the cost of investigation is frequently underestimated by management, leading to the decay of supporting systems like catalogs.

The uncomfortable part

The reason ownership data goes wrong is that keeping it right is unplanned operational work. It is a task with no ticket and, ironically, no owner. Until we treat the maintenance of our service ownership model as a first-class engineering requirement—or automate the extraction of context from the code itself—we will continue to be misled by catalogs that aren't down, but are simply, confidently wrong.