Work can continue, but shipping needs a plan. Git keeps full history on each developer's machine, so commits, branches and diffs keep working. What stops are pull requests, reviews, hosted CI and anything that pulls from the host. Prepare a mirror, a review path and a documented emergency release route.
What still works and what does not
The Git documentation describes most operations as local: because you have the entire project history on your disk, most operations need just local files. That is why a hosting outage does not stop a developer from committing or comparing changes.
| Activity | During a hosting outage |
|---|---|
| Commit, branch, diff, log | Works locally |
| Push and pull to the host | Fails |
| Pull request review | Blocked |
| Hosted CI and required checks | Blocked or stale |
| Package and image builds that fetch from the host | Likely to fail |
| Deploys triggered by a merge | Do not start |
Prepare in advance
- Keep a mirror. A bare clone of each important repository, refreshed on a schedule on infrastructure you control, gives you a place to fetch from. Confirm it contains all branches and tags.
- Decide an alternate sharing path. Developers can exchange work through another remote, a bundle file, or patches. Pick one and write down the commands.
- Know your build inputs. If your build pulls a dependency straight from the host, vendor or cache it so a build is possible without the host.
- Keep a way to run checks locally or on a spare runner. The same checks you run in CI should be runnable from a script.
- Write the emergency release path before you need it. See below.
An emergency release without the host
An urgent fix is where teams are tempted to skip review. Decide in advance what the minimum acceptable path is.
- Two people. One writes the change, another reads the diff from the mirror or a patch.
- The same checks. Run your usual tests and any security scans from the local script.
- A recorded decision. Note who approved the exception, what was skipped, and when the normal process resumed.
- Reconciliation. When the host returns, push the change through a normal pull request after the fact so history, review records and required checks catch up. Forward port the change to the main branch so it does not vanish.
If you have branch protection rules, remember they live on the host. An alternate path does not enforce them, so people must. Our posts on shipping a hotfix when CI is down and security checks in a hotfix go deeper.
Protect the alternate path
A mirror is a copy of your source, so give it the same access control as the original. Review who can read and write it, and log access. Avoid tokens in scripts that sit in shared folders.
A worked example: a four hour hosting outage
This example is hypothetical. A team of eight engineers uses a hosted Git service for source, reviews and CI. At 09:00 the service becomes unreachable. A customer reports a bug at 09:30 that needs a fix the same day.
| Time | What the team does | Why it works |
|---|---|---|
| 09:35 | Incident lead declares the alternate path | Decision rights were written in advance |
| 09:40 | Engineer pulls from the team's internal mirror, updated an hour ago | The mirror was set up earlier |
| 10:15 | Fix written, tested locally with the same script CI uses | Checks can run without the host |
| 10:30 | Second engineer reads the diff as a patch file by email or chat | Review without the hosted tool |
| 10:45 | Build runs on a spare runner using vendored dependencies | Build inputs do not depend on the host |
| 11:00 | Artifact is signed and deployed through the emergency path | Signing key is separate from the host |
| 13:00 | Host recovers; the engineer opens a pull request with the same change | Records catch up |
| 13:30 | Required checks run and the pull request is approved retroactively and merged | History and review record are complete |
The key point is the last two rows. The team did not stop reviewing. It changed how review happened and reconciled afterward.
Step by step: setting up the mirror
- Pick the repositories that matter most, usually those behind your customer facing services and your infrastructure code.
- Create bare clones on a server you control, and configure a scheduled job to fetch all branches and tags. Include submodules or large file storage if you use them.
- Restrict access to the mirror with the same groups as the original, and log reads and writes.
- Test a fresh clone from the mirror and run a build from it.
- Monitor the freshness of the mirror and alert when it falls behind.
- Write the three commands a developer needs to repoint a local clone to the mirror, and keep them in your offline runbook.
What you cannot mirror easily
A Git mirror holds code and history. It does not hold issues, pull request discussions, review approvals, project boards, wikis or CI configuration stored in the service's own format. Decide which of those you need during an outage and set up a periodic export. At minimum, keep an export of your open work and your CI definitions where you can read them.
Secrets and signing
An outage plan must not push secrets into places they should not be. Keep signing keys and deployment credentials out of the repositories, and out of the mirror. Check that your emergency build path can reach the signing key through a controlled process. Our post on rebuilding the CI/CD pipeline after an outage or compromise goes further.
Reconciliation checklist
- Open a pull request with the exact change that was shipped.
- Attach the record of who reviewed it and what checks were run.
- Let required checks run and fix anything they find.
- Note in the incident record which controls were bypassed and why.
- Update the plan with what you learned.
Try it yourself
Open the pull request gate demo and look at how a change is checked before it merges. Think about which of those checks you would run locally during an outage, and which you would reconcile afterward.
Click through it at your own pace, or open it full screen.
Quick check
Is a developer's clone a backup?
It holds history, but it may be missing branches, other people's work and settings kept on the host such as issues and review comments. A scheduled mirror plus an export of hosted data is a fuller plan.
Should we skip review during an outage?
Avoid skipping it. Use a lighter path, such as two people reading a diff, and reconcile with a pull request afterward.
Is a mirror a security risk?
It is another copy of your source, so protect it like the original with access control, logging and encryption. The risk is manageable when it is treated as a real system and not a convenience.
Sources
Last reviewed: 19 October 2026.
