The Repo Nobody Owns Is the One That Will Bite You

The 14,000-repo problem

GitHub has over 14,000 repositories across their primary internal organization. As of early 2025, about 11,000 of those were non-archived. The vast majority had no clear owner.

Production services had ownership through their Service Catalog. Everything else -- team repos, documentation, internal tools, hackathon projects, one-off experiments, personal prototypes -- was a black hole. If you needed to contact the owner of one of those repos, the workflow was: check commit history, read the README, ask in Slack, guess based on the repo name. Repeat for every repo.

For a one-off request, that is annoying. For recurring security workflows that fan out across the entire organization, it is a real blocker.

Why ownership matters: the secret scanning bottleneck

GitHub's secret scanning was finding secrets. The team could technically rotate a leaked credential. But rotating without knowing who owned the repository was risky and often disruptive. They had no reliable way to route remediation work. Every alert turned into a detective operation.

The same pattern plays out in every growing organization. Security, compliance, incident response, dependency updates, license audits -- they all need to know who owns what. When that information does not exist, every cross-cutting initiative stalls while someone does manual ownership archaeology.

The old model: good for services, nothing for everything else

GitHub already tracked ownership for deployed services through their internal Service Catalog. Each service entry recorded metadata: which repository it lived in, the owning team, executive sponsor, support contacts.

The problem was the relationship was many-to-one. A service could only attach to one repository, but a repository could have multiple services. If you started from a service, you could find its repo and owners. If you started from a repository and needed an owner, you had to reverse the lookup, and that only worked for repos that mapped to a service.

Everything that was not a deployed service -- team repositories, documentation, internal tools, one-off projects, personal experiments -- fell through the cracks.

The fix: make ownership a first-class property

GitHub chose to use GitHub custom properties. Two properties:

• ownership-type: a single-select with three values -- "Service Catalog," "Team," and "Hubber Handle" (individual). This covered every realistic ownership scenario at GitHub. A repository either belongs to a service (on-call team, defined lifecycle), a team (shared docs, internal tool), or an individual (personal project, experiment).
• ownership-name: a text field with validation. Hubber handles checked against actual org membership. Teams verified to exist with at least two members. Service Catalog entries confirmed against the Service Catalog itself. They were intentionally permissive on formatting -- if someone typed @my-team instead of my-team, they accepted it.

Day-one coverage: sync what you already know

Before asking anyone to do anything, GitHub built a periodic sync from Service Catalog to repository custom properties. Every repository that backed a known service got ownership-type="Service Catalog" and ownership-name populated automatically. That took care of about 1,500 service-backed repos with zero human effort.

This is the smartest move in the whole playbook. You do not ask people to fill in what you already know. You populate the easy stuff first, then ask people to fill the remaining gaps. Starting from a blank slate would have felt overwhelming. Starting from 1,500 pre-populated repos made the remaining gap feel tractable.

The rollout: Saturday was a mistake

GitHub built a GitHub App backed by a Kubernetes CronJob. They scheduled the first run for a Saturday morning thinking nobody would be paying attention.

Big mistake. Issues started appearing in repositories across the organization. People jumped on Slack asking about this new issue in their repository threatening to archive it. At a globally distributed company, someone is always online.

The enforcement workflow was: the CronJob opened an issue in every repository without ownership set. The issue gave a 30-day grace period. After 30 days, any repository that still did not have ownership set was archived.

Archiving was a deliberate choice. It is reversible and non-destructive: the repository becomes read-only, GitHub Actions stops running, but nothing is deleted. If someone needs it again, they unarchive, set ownership, and continue. Choosing a reversible action let them apply archival broadly instead of debating every edge case.

Once the initial pass was done, they tightened the enforcement loop from 30 days to one hour. A new repository that somehow bypassed creation-time ownership would get flagged almost immediately.

The sharp edges

Two incidents stand out.

Incident 1: The Datadog repo that got archived. Datadog had been configured to open issues in a repository as part of a monitoring workflow. When the repo was archived and Datadog could not create the issue, the internal monitoring service automatically paged the owning team, who escalated. The root cause: ownership issues were landing in repositories, but nobody was getting notified directly. The fix: @-mention repository administrators and assign all users with write access as a fallback on ownership issues. The issues could not be buried.

Incident 2: Stale data. The app was robust against a Service Catalog outage, but nobody considered that the Service Catalog might return stale or corrupted data. If bad data caused the app to think a batch of repositories had lost their Service Catalog entries when they had not, the app would mass-archive repos with perfectly valid owners.

The fix: a low water mark. Before each run, the app tallied how many archives it was about to perform. If the number exceeded a conservative threshold, it bailed out entirely and triggered a Datadog monitor rather than risk a bad run. If Service Catalog was unreachable, the job skipped Service Catalog validation and only checked what it could verify independently.

Results, by the numbers

• 14,000+ repositories at the start
• Under 45 days from first run to steady state
• About 3,000 active repositories with validated owners
• About 11,000 archived (up from 3,000 archived at the start)
• Every active repository now has a validated owner, or it gets archived within one hour
• Many archived repos had not seen a commit in years: abandoned experiments, completed hackathon projects, even one-person prototypes from 2008
• Repository creation now requires ownership properties, so the inventory stays clean going forward

What to steal for your own org

Define your ownership taxonomy. Services, teams, and individuals worked for GitHub. Your categories might look different, but have categories. A free-text "owner" field is not ownership.

Sync what you already know. Populate ownership for repositories you already track through a service catalog, asset inventory, or observability tool. That is the fastest way to go from zero to meaningful coverage.

Make ownership required at creation time. Enforcement is hard retroactively. A required field on the first commit is painless.

Build a grace-period workflow for existing repos. Open issues with a reasonable deadline. Archive repos that go unclaimed. Reversible actions let you be aggressive.

Build guardrails before you trust automation at scale. A low water mark and a notification fallback were not in the original design. They came from real incidents. If you build a system that archives repositories or opens issues at scale, assume your data sources will occasionally be wrong and your notifications will sometimes get lost. Design for that from the start.

Do not run your first enforcement pass on a Saturday.