Deleting a GitHub Repository: The Danger Zone and What Goes With It

Deleting a repository lives at Settings → General → Danger Zone → Delete this repository, and requires typing the full owner/name to confirm. You need admin rights on the repository or ownership of the organisation. What the confirmation dialog does not spell out clearly is the collateral: issues, pull requests, wiki, releases, packages, and — if the repository was private — every fork of it.

It is a short task with a long tail of consequences, so the useful version of this article is less about the clicks and more about what to check before them.

Table of contents

• The steps
• What gets deleted along with it
• Do this first: check what depends on it
• Take a copy before you delete
• The alternatives worth considering first
• Can you undo it?
• How this fits the rest of the stack
• FAQ

The steps

1. Open the repository on GitHub and click Settings in the repository’s top menu. If you cannot see it, you do not have admin rights on that repository.
2. Stay on the General tab, which is selected by default, and scroll to the bottom.
3. Find the Danger Zone section and click Delete this repository.
4. Read the consequence list in the dialog. It is repository-specific and worth actually reading.
5. Type the full owner/repository-name exactly as shown.
6. Click the final confirmation button. On accounts with two-factor authentication you will be asked for a code.

The typed-name confirmation is deliberate friction. It is the only thing standing between a misplaced click and a repository that is gone, so the fact that it is mildly annoying is the feature.

What gets deleted along with it

The dialog summarises this, but people click past it. The full list is worth knowing in advance.

• All issues and pull requests, including their comment history and review threads
• The wiki, if the repository has one
• Releases and any binaries attached to them
• GitHub Pages sites served from the repository — the URL stops resolving
• Packages published from the repository to GitHub Packages
• Actions run history, artifacts, and repository-level secrets
• Stars, watchers, and the repository’s contribution graph entries

Forks of a private repository are deleted too. Public repository forks survive and become independent, but a private repo’s forks go with it. If someone in your organisation forked a private repository to work on it, their fork disappears when you delete the parent.

Do this first: check what depends on it

Repositories accumulate references. Before deleting one, spend two minutes on the things that break silently.

• Deploy connections. Any hosting platform building from the repo will fail its next build, and webhook deliveries start erroring.
• Submodules and package references. Another repository pinning this one by URL breaks on next clone or install.
• CI in other repositories that checks this one out, or reuses a workflow from it.
• Documentation links pointing at files, issues, or releases.
• Published packages — if anything installs from GitHub Packages here, deleting is a supply break for consumers.

The dependency you forget is usually a deploy hook. A repository nobody has committed to in a year can still be the thing rebuilding a live site every week.

Take a copy before you delete

A local clone captures code and history but not the GitHub-side metadata. If issues matter, export them separately.

# Full mirror, all branches, all tags, all refs
git clone --mirror git@github.com:acme/old-service.git

# Verify before you rely on it
cd old-service.git
git log --oneline --all | head
git branch -a

A --mirror clone is bare and includes every ref, which a plain clone does not. For issues and pull request bodies, use the GitHub CLI:

gh issue list --repo acme/old-service --state all --limit 1000 \
  --json number,title,body,state,createdAt,comments > issues.json

GitHub’s account-level Settings → Migrations export is the thorough route when the repository has years of discussion attached to it.

The alternatives worth considering first

Deletion is rarely the only option and is the only irreversible one.

• Archive it. Settings → Danger Zone → Archive. The repository becomes read-only, stays visible, keeps its issues and history, and can be unarchived. This is the right answer most of the time.
• Make it private. Removes it from public view without destroying anything.
• Transfer it. If the project has a new owner or is moving to an organisation, transfer preserves issues, stars, and — usefully — sets up redirects from the old URL.
• Rename it. GitHub redirects the old name, so links keep working.

Archiving covers the actual need — “this is not active, stop showing it to me as though it were” — without the irreversibility.

Can you undo it?

Within 90 days, sometimes. GitHub can restore a deleted repository if it was not a fork, the name has not been reused, and the deletion was recent. It is a support request, not a button, and it is explicitly not guaranteed.

Treat restoration as a lucky outcome rather than a plan. The mirror clone from two sections up costs thirty seconds and does not depend on anyone’s goodwill.

Deleting through the API has exactly the same effect and no extra confirmation, which is worth remembering before scripting a cleanup:

# No undo, no dialog. Be sure.
gh repo delete acme/old-service --yes

How this fits the rest of the stack

The mechanics are six clicks in the Danger Zone. The judgement is in the two minutes before: take a mirror clone, check what deploys or installs from it, and ask honestly whether archiving does the job. Private-repo forks going with the parent is the consequence that surprises people most.

If the repository was building and deploying something, that connection is the piece to re-point rather than lose. Deploying from a GitHub repository, with build logs and a route per service, is the normal path on RunxBuild — and if you are working out what the replacement costs to run, the RunxBuild hosting calculator breaks it into service, database, storage, and bandwidth rather than one lump figure.

Useful related references:

• Undo Commit on GitHub: What You Can Do in the Browser and What Needs the Terminal
• Bitbucket vs GitHub: A Decision About Your Toolchain, Not Your Git
• actions/setup-node: The GitHub Actions Node Setup That Does Not Fight Your Deploy
• Deploying from GitHub on RunxBuild

FAQ

Where is the delete option for a GitHub repository?

Settings → General tab → scroll to the bottom → Danger Zone → Delete this repository. You must have admin permission on the repository or own the organisation that holds it. If the Settings tab is not visible to you, your role does not include that permission.

Does deleting a repository delete its forks?

Forks of a private repository are deleted with it. Forks of a public repository survive and become standalone repositories under their own owners. This asymmetry catches teams out when someone has forked a private repo to work on a feature.

Can I recover a deleted GitHub repository?

Sometimes, within 90 days, via GitHub Support. It has to not be a fork, and the name must not have been reused. Restoration is discretionary rather than guaranteed, so take a git clone --mirror before deleting instead of relying on it.

Should I archive instead of delete?

Usually yes. Archiving makes the repository read-only while keeping code, issues, history, and URLs intact, and it can be reversed. It satisfies the common motivation — the project is finished and should stop looking active — without the permanence.

What happens to GitHub Pages when I delete the repository?

The Pages site stops being served and the URL no longer resolves. If a custom domain pointed at it, that domain now serves nothing until you repoint the DNS. Move the site somewhere else and confirm it is live before deleting the source repository.