Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Incident with Actions and Pages

githubstatus.com

Post reply on HN
Print view View original

101–110 of 407 posts

Re: Incident with Actions and Pages

#103

Post by bobmcnamara »

sh-cho wrote: post #24

'Degraded' should be banned in status pages. It sounds just irresponsible, like "Yeah, it can be slow or something sometime. Whatever. Who cares"

The whales are all dying, and we don't know why. Well, some are still alive for now though so maybe it's not so bad...

Re: Incident with Actions and Pages

#104

Post by kylegalbraith »

heeton wrote: post #71
kylegalbraith wrote: post #52

Earlier quoted context omitted.

Founder of Depot here. To my knowledge, we are the first engine to support different syntaxes in this compatible way via Depot CI [0]. Great time to try it out and let us know your thoughts! We’ve built a lot of cool stuff into it like parallel steps, custom images, and a full CLI/API interface so you can literally everything without going into the web app. [0] https://depot.dev

As someone who partially uses depot but was still affected by this github issue, we obviously haven't moved over enough. We use your runners but github is still blocking us. Hope you don't mind the public ask, it seems useful for others. If we're using depot runners, and want to use them directly, or move off of github actions being the controller for when things run: what do you suggest? Trigger the workflows direct…

Yes, triggering Depot CI via the CLI is the sure fire way to avoid all dependencies on GitHub.

We’d need more details around what you’re seeing. It is true that if auth across GitHub is broken than we can’t copy your actions out to be used by Depot CI. However, we have a solution in the works for that as well.

In short, Depot CI, our own engine and control plane is not dependent on upstream actions control plane. But still has to listen for commit events to know if/when to run jobs on things like PRs. This to is being removed in the future.

Re: Incident with Actions and Pages

#106

Post by gilrain »

datsci_est_2015 wrote: post #60
gilrain wrote: post #42

Earlier quoted context omitted.

No, it doesn’t. Their competition is not similarly unstable, despite existing in the same world of LLMs. Think critically.

Devil’s advocate, Pareto heuristic would let us speculate that 80% of LLM traffic would be aimed directly at the largest provider, i.e. GitHub.

Your speculation is that their competitors would naturally not see a commensurate increase in instability while “only” handling 20% of the same crisis?

I don’t buy the excuse. I want to hitch my wagon to those “mysteriously lucky” competitors. (And have. And haven’t had similar issues to Github, since.)

Re: Incident with Actions and Pages

#108

Post by TheDong »

echelon wrote: post #83
jaapz wrote: post #62

Earlier quoted context omitted.

All these monitoring rules are of the format "when 500 errors > baseline for x minutes". Otherwise you'd have monitoring alerts every second. So it is normal for users to already see errors before github officially counts it as an outage.

In a high performance service with good maintenance and upkeep, you page for all 500s. A noisy pager forces the team to fix the 500s. Maybe the Github Actions infrastructure isn't run like that. edit: my oncall rotation notified on all 500s, 24/7, not just rates - https://news.ycombinator.com/item?id=48279262

Do you know of a single service at a single company that actually does that?

I know all of Gmail, every GCE service I can think of, every AWS service I can think of, Amazon.com, Netflix, and Github all do not page on just a single 500.

I know none of those are particularly "high performance" though. Curious where your experience is coming from.

Post reply on HN