A deleted GitHub repository can be restored within 90 days, from the settings of the account or organization that owned it. It may take up to an hour after deletion before it appears as restorable. Restoration is blocked in some fork situations, and team permissions do not come back with it.
What GitHub documents
GitHub's documentation on restoring a deleted repository states the following:
- The window is 90 days.
- It can take up to an hour after deletion before the repository can be restored.
- You restore from the settings of the personal account that owned it, or of the owning organization.
- If the repository was part of a fork network that still has other repositories in it, restoration is blocked until every other repository in the network is deleted or detached. A fork network includes the parent, its forks, and forks of those forks.
- For a fork network that still has members, you need to contact GitHub Support, and only users on a paid plan can do that.
- Team permissions are not restored with the repository.
The documentation does not say which organization roles may restore, so check your own organization settings rather than assuming.
Runbook: first hour
- Do not recreate the name yet. If you create a new empty repository with the same name, you may confuse the restore and your tooling. Hold off until you know the outcome.
- Find out who deleted it and why. Use the organization audit log to see the actor and time. If the actor is an account that should not have done this, treat it as an account compromise and follow your account incident steps first.
- Check for a local copy. Any developer who cloned the repository has the full history. A recent clone on a laptop or a CI runner cache can be your fastest recovery. Ask everyone to stop pulling, fetching with pruning, or deleting local clones until you have a safe copy.
- Start the restore. Wait out the hour if the repository is not offered yet, then restore from settings.
- Check fork networks. If restoration is blocked, list the forks and decide whether to contact Support or detach forks you own.
After the restore
Verify what you got back. Compare the default branch tip against a local clone. Then rebuild what is not restored:
- Team and collaborator permissions, which GitHub says are not restored.
- Anything else you configure around the repository, such as webhooks, secrets, deploy keys, branch protection and integrations. The restoration page lists team permissions only, so check each of these against your records instead of trusting the restore.
If you manage settings as code, reapplying them is quick. If you do not, this incident is a good reason to start.
Why 90 days is not a backup plan
The window is a safety net for mistakes. It does not help if the deletion goes unnoticed for months, if the fork network blocks restore, or if you are not on a paid plan and need Support. Keep your own copy of anything the business cannot lose.
Practical steps:
- Keep a scheduled mirror of important repositories in a separate account or storage, and test restoring from it.
- Limit who can delete repositories in the organization.
- Alert on repository deletion events from the audit log.
- Store repository settings as code.
The same discipline applies to data backups. See the backup restore test guide for small teams.
Quick check
How long do we have to restore a deleted repository?
GitHub documents a 90 day window, with up to an hour of delay before the repository can be restored.
Do permissions come back with the repository?
Team permissions are not restored, according to GitHub. Reapply them and check other settings against your records.
Sources
Last reviewed: 19 October 2026.
