On the evening of Thursday 22 October, GitHub suspended my account, creativeheadz. The first failure landed at 20:01 UTC. I received no email, no warning and no reason in any mailbox I own.
This is what a suspension looks like from the outside. The API answers with one line: sorry, your account was suspended. A push is refused with a 403. The profile, every repository, the project sites, the container images and both security advisories return not found, as though none of them had ever existed.
Since then I have had exactly one substantive reply. I filed a reinstatement request the same evening, ticket 4894010, describing the account, the Tigris release and the published advisory, and asking what had triggered the suspension. Support answered that some activity on the account had been flagged by abuse-detection systems for manual review, as it may conflict with the Terms of Service, and asked how I plan to use GitHub. I answered in detail: years of my own projects, Actions for CI and deployment, production servers pulling on a timer, the Tigris security tool with its v4.0.0 release and published advisory. I said I plan to keep using it exactly that way, asked whether the automated pulls or the security tooling were the trigger, and offered to change either. That was the whole exchange. I still do not know what I am supposed to have done.
The minute everything failed
The suspension took seconds. The damage took about a minute, because that is how tightly I had wound my automation around one vendor. Wegweiser deploys by autopull: every minute, production and staging fetch the repository and move forward. From 20:01 both servers logged repository not found, every minute, and production sat frozen on its last commit. This site deploys the same way, through a timer that pulls from GitHub, so it shared the same single point of failure. My next commit never left my checkout. The push was refused and the work stayed stranded on my own disk.
Then the rest of the stack fell over in turn. CI runs on GitHub Actions, so no push gets tested anywhere. Agent releases ship through a release workflow and GitHub Releases, so no new agent build can reach the fleet, and the hourly mirror check gets a 403 on the latest release. Issue filing for Health Insights, the blog-draft workflow, the blog routine and a perimeter canary all live on the same account, so they went dark together. The Tigris release, its website, its container image and its two advisories vanished with the account, which also blocked the CVE requests built on them. Thirty other private mirrors on my Gitea, all pulling from GitHub, stopped syncing at the same stroke.
It was never just code hosting
Read that list again and notice its shape. It was never just code hosting. One vendor held my source, my deploys, my tests, my releases, my registry and my advisories, and one unexplained decision switched all of them off at once. There was no conversation, no call, no human being. There was a form. That is the arrangement every repository on someone else's forge is really in. It works until the day it does not.
The forge under my own roof
What saved the week was the forge I already ran at home. For a while I have kept a house Gitea at git.oldforge.tech, on a small virtual machine on my own network, pull-mirroring my GitHub repositories. The Wegweiser mirror had synced not long before the suspension, current to the last commit. A mirror cannot take pushes, so I renamed it aside, created a fresh private repository in its place, and filled it with a verified mirror push from a clean clone: every branch, all 126 tags, identical ref for ref. The only things Gitea refused were GitHub's own pull-request refs, which belong to the vendor and not to the project.
The cutover was almost boring, which is the highest praise a failover can earn. Both servers already carried the same read-only deploy key, so I registered that key on the new repository, pointed each checkout at the Gitea address over SSH, and changed nothing else. The pull script and the crontab stayed exactly as they were. I pushed the refused commit to the new origin and both servers deployed it on their next minute. My working clone now treats Gitea as origin and keeps GitHub as a second remote, waiting for the day the account returns, if it returns.
What is still broken
I will not pretend everything is healed. CI still has no home, because the workflow files were written for GitHub's runners and would fail on mine until I adapt them, so every push now starts with the test suite run by hand. Agent releases, issue filing and the rest remain homeless too. The mirror fleet still points at accounts I cannot reach. Gitea bridged the incident. It did not erase it.
Two findings from the audit are worth keeping. First, the Tigris package on COPR kept installing through all of this, because its source package carries the source instead of fetching it from a forge at build time. Every artefact that can carry its own source should. Second, while checking the blast radius I found plaintext GitHub tokens committed in old corners, one in a git config and one in a setup note from last year. They are queued for rotation the moment the account is back. An incident is a fine time to find the things you should have found earlier.
Asking under the GDPR
In parallel I filed a subject access request under Article 15 of the UK GDPR, asking for everything GitHub holds on the account: the abuse-detection flags, the flagged activity with timestamps, addresses, endpoints and repositories, any risk scores, the staff notes, and whether the suspension was a solely automated decision. The privacy inbox answered with an automated reply pointing at self-service pages that require signing in, which a suspended account cannot do. I wrote back to say so and to put the one-month deadline on record: 23 November 2026. If the decision was automated, I have asked for a human review, and I contest it.
The lesson
Here is the lesson, stated once. A vendor's interests are the vendor's, and no amount of good service changes whose hand is on the switch. Keep your origin on iron you control, let the big forge be the mirror and not the master, and make sure a single 403 can never again freeze your deploys, your tests and your releases in the same minute. I learned that this week. The appeal may give me my account back. It will not give GitHub my origin back.
