To recover a deleted GitHub repository, go to your account settings, open “Deleted repositories,” and restore it within 90 days of deletion — as long as the repo wasn’t permanently deleted, the name hasn’t been reused, and (for forks) the network still allows it. That’s the good news. The rest of this article is the honest part: when that window works, when it quietly doesn’t, and what to do if you’re already past it.
Take a breath first. If you just deleted a repo, you have not necessarily lost it. GitHub keeps a recovery path open for a limited time, and for most accidental deletions, that path is enough. But it comes with conditions that nobody reads until they’re panicking, and if you fall outside them, native recovery gives you nothing. This is a place where a little clarity beats a lot of frantic clicking.
Here’s the wider context worth knowing: 40% of SaaS users have lost data at some point, and the single most common cause across the industry is human error, with 90% of data leaks attributed to it. A deleted repo is that statistic wearing a hoodie at 11pm. You’re not careless. You’re normal.
Can you recover a deleted GitHub repository?
Usually yes, and within limits. GitHub provides a self-service restore option for repositories you’ve deleted, accessible from your account or organization settings. If the deletion was recent and the repo hasn’t been permanently purged, you can bring it back yourself without contacting support.
Restoration is possible when all of these are true:
- It’s been fewer than 90 days since deletion.
- The repository wasn’t permanently deleted (some deletions, or accounts under certain conditions, don’t retain the restore option).
- The repository name hasn’t been reused. If you or someone else created a new repo with the same name, the old one can’t be restored to that name.
- For forks, network conditions still allow it. A fork’s recoverability can depend on the state of its parent (upstream) repository. If the upstream network has changed, the fork may not come back cleanly, or at all.
One honest caveat: even a successful restore may not return everything. Some elements — certain webhooks, integrations, or ancillary metadata — may not fully reattach. The code and commit history are the priority; treat the rest as “verify, don’t assume.”
How long do you have to restore a deleted GitHub repo?
You have 90 days. After that, the repository is generally gone from GitHub’s self-service recovery, and support is unlikely to retrieve it for you. The clock starts at the moment of deletion, not the moment you notice.
Ninety days sounds generous. In practice, the repos people most want back are often the ones deleted quietly — an old side project, a “temporary” clone, a fork tied to a job you’ve since left. By the time anyone realizes it mattered, the window can already be closing. If you’re reading this in a panic, check the date of deletion now, before you do anything else.
How to restore a deleted GitHub repository (step by step)
- Go to your account settings. Click your profile photo (top-right), then Settings. For an organization-owned repo, go to the organization’s settings instead — you’ll need owner permissions.
- Open “Deleted repositories.” In personal settings this lives under the Repositories section. Organizations have an equivalent list.
- Find the repo in the list. Only repos still inside the 90-day window and eligible for restore will appear.
- Click Restore, then confirm. GitHub will ask you to confirm the repository name.
- Wait, then verify. Restoration can take a few minutes for larger repos. Once it’s back, check your branches, tags, commit history, collaborators, webhooks, and any CI/CD integrations. Re-authorize anything that didn’t reconnect.
If the repo doesn’t appear in the list, one of the conditions above wasn’t met. Most often the name was reused, the fork’s upstream changed, or you’re past 90 days.
What if native recovery doesn’t work?
This is where the panic in the support forums lives — the “⚠️ URGENT: Help Needed to Recover Deleted Forked Repo” threads. If the repo isn’t in your Deleted repositories list, your realistic options narrow fast:
| Situation | Can you recover it? |
|---|---|
| Within 90 days, name unused, not permanently deleted | Yes — self-service restore |
| Past 90 days | No — native recovery is closed |
| Name already reused | No — not to that name |
| Fork with a changed/deleted upstream | Maybe not — network conditions may block it |
| You have a full local clone | Partially — you can re-push code + history, but not GitHub-side metadata (issues, PRs, settings, permissions) |
That local-clone row is the one people cling to, and it’s worth being precise about. A git clone on your laptop holds your commits and branches. It does not hold your issues, pull requests, code review history, releases, project boards, wikis, webhooks, or access settings. Those live only on GitHub’s side. Re-pushing gets your code back; it does not get your project back.
Why “GitHub has it” isn’t a backup plan
Here’s the uncomfortable reframe: GitHub’s 90-day window is a courtesy, not a backup. It’s a short grace period for undoing a mistake, not a durable safety net you can rely on. And it doesn’t cover the failure modes that actually hurt: a departing admin who deletes repos on the way out, a bad script or automation that wipes branches, a compromised account, or a deletion nobody catches for four months.
This is the Shared Responsibility Model in action. GitHub is responsible for keeping the platform running — uptime, infrastructure, availability. You are responsible for your own data and being able to get it back. GitHub says so plainly in its own terms: “We will not be liable for any loss of profits, use, goodwill, or data.” That sentence is doing a lot of quiet work. Read more on the Shared Responsibility Model.
There’s also a subtler trap. Relying on a copy that lives inside the same platform you’re trying to protect against is like backing up your hard drive to your hard drive. That’s the whole point of the 3-2-1 backup rule: keep three copies, in two locations, with one copy fully independent of the SaaS provider. A repo GitHub is holding for you doesn’t count as independent.
The only reliable fix: back up before you need it
I’ll be straight with you, because I’ve been the person staring at an empty repo list. The one approach that reliably survives a deleted GitHub repo is a third-party backup installed before the deletion. Not after. There is no tool (including Rewind) that can reach back and recover data it was never protecting.
With a backup in place ahead of time, the panic scenario becomes a non-event. Rewind continuously backs up GitHub repositories and the metadata around them, and lets you restore what you need without depending on GitHub’s 90-day courtesy or your luck with fork network conditions. (Fun bit of heritage: Rewind’s GitHub backup grew out of BackHub, so this is well-worn ground for us.) You get real retention — a 365-day default, configurable much further — instead of a countdown clock.
The move here is simple, and it’s the same move for every developer who’s read a thread like this one and thought “that could be me”: set up the backup now, while nothing is on fire.
FAQ
Can GitHub support recover a repo after 90 days?
Generally, no. Once the self-service window closes, the repository is typically unrecoverable through GitHub. This is exactly why a pre-emptive backup matters.
Does a local clone count as a backup?
Partially. It preserves your code and commit history, but not issues, pull requests, releases, settings, or permissions, all of which live only on GitHub.
Can I recover a deleted forked repository?
Sometimes. Forks depend on the state of their upstream (parent) repo. If the upstream network has changed or been deleted, the fork may not restore cleanly, even inside the 90-day window.
Will restoring bring back my webhooks and integrations?
Not always. Restore prioritizes code and history; some webhooks and integrations may need to be reconnected or reconfigured manually.
How do I make sure this never happens again?
Install a third-party backup that runs independently of GitHub, following the 3-2-1 rule. It’s the only method that protects you after the 90-day window and outside the conditions GitHub’s native restore requires.
Deleting a repo is a bad afternoon. Losing it permanently is a bad quarter. The difference is almost always whether a backup was already running.
Talk to a SaaS resilience expert at Rewind to protect your GitHub repositories and metadata before you need to recover them.
And if you’d rather get this kind of practical, been-there guidance in your inbox, subscribe to Retro, Rewind’s newsletter for people who own their data’s survival.
Dave North">
