Don't know about you but at this point I've learned to recognize and ignore GitHub issues even when they haven't admitted to it yet

I assume these companies have some kind of uptime guarantee in their contracts, because they seems to care more about covering their asses than about informing customers.

Disclaimer: I am building a code forge at https://juju.bi

  def is_github_down(day):
      return day[-1] == "y"

You're literally replacing a well designed resilient system with a single point of failure run by a different company...

Gitea Enterprise would be worth looking at.

https://about.gitea.com/products/gitea-enterprise/

https://gitsocial.org/

Begin by refactoring the deployments so they're driven by checked in shellscripts, that accepts a git reference to deploy (prefer immutable commit SHAs over mutable branches/tags). Make it use the stuff it already has checked in, and make the actual GitHub Actions stuff as small and concise as possible, ideally each "run" should just call a shellscript with the git reference.

Then move so the deploys happen not on GitHub Actions itself, but on a "intermediate deploy host" that has the source code and access to the credentials you need, and make this host have one secure entrypoint, where someone (or something) can enter and run shellscripts, after pushing their code as a normal git push. Then switch so the deploys from GitHub Actions instead use this new host to do the deploys. Lock down this host hard.

When GitHub and/or GitHub Actions go down, the developer responsible for deploying stuff, should be able to get temporary git and ssh access to this host, can push any git data straight to the host, and their user on this host can run the deploy scripts. Keep in mind that nothing in your deployment process should depend on stuff that isn't also available on this "deploy host", if you have multiple synced repositories and so on.

Now things mostly work the same as people are used to, with the added benefit that when things go down again (like next week), you'll still be able to continue to deploy stuff.

I've done this refactor/migration for tens of companies in the last year, more or less following this exact template for all of them, with no issues reported from either of them, but lots of praise :)

> git@github.com: Permission denied (publickey). fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

git -c credential.helper= -c 'credential.helper=!gh auth git-credential' pull https://github.com/myorg/my-repo.git

Developers are expensive. If I can't ship a feature on time because GitHub issues keeps forcing me to switch to different tasks to work around git/PR/ticket/Actions downtime, then that costs my company real money - despite us not being the source of the AI DDoS that GitHub has happily been welcoming.

To me, the situation is very simple: either 1) rein in the AI deluge, or 2) isolate paying customers from it, or we'll move to an alternative.

For businesses the current state of unreliability would be unacceptable if it was completely free, the fact that it is actually paid just adds insult to injury.