Live data from Hacker News

Incident with Actions and Pages

githubstatus.com

261–270 of 407 posts

Re: Incident with Actions and Pages

#261

The last two projects I built I did the CI/CD manually with a small win32 service that polls git and builds+deploys the main service locally. It's barely 200 lines of code. Not much to go wrong. "dotnet publish" is not difficult to wrap. The latest language models have enabled this sort of thing for me. I can integrate a mini Jenkins into every project within a 5-10 minute prompting session. This sort of code isn't h…

That works for relatively simple scenarios. When you have to add deploying sql changes or something having to update something in the cloud, you'd have to include a lot more plumbing.

Deploying SQL changes? Why not just let the application do that on startup. Ofcourse be backward and forward compatible. SQL change only deploy.

"Update something in the cloud" <- What do you mean?

Re: Incident with Actions and Pages

#262
post #257

Earlier quoted context omitted.

Because scaling complex systems is not trivial

It was pretty easy before October 2018, when Microsoft bought them: https://www.githubstatus.com/uptime?page=31

Scaling to human use vs automated/agentic use is a very different thing.

Re: Incident with Actions and Pages

#263
post #208

Earlier quoted context omitted.

You should never entirely depend on a third party service for deployments. Been burned too many times on that one.

Ok. Move to EC2. Darn AWS is down. Alright, run it on a Mac Mini in your basement. Ahh dawn, your ISP is having issues. Good thing you have a backup 5G hotspot. Ohh no, the power is out. Eventually you have to trust someone else. GitHub is a tragedy of the Commons. Too many people are using it, and Microsoft isn't willing to handle it correctly. Feels like a very good business opportunity. Minimum 50k yearly contract…

Maybe we need a split between source management and distribution? The former looks like git[hub] to me, the latter maybe more like a Linux distro repo?

Re: Incident with Actions and Pages

#264

We’ve had GitHub actions for long enough, it’s time for GitHub consequences.

>Copilot: Do you want me to implement consequences for you or babble on and on about what might entirely be a figment of your imagination (Github is up and you're on a 48 hour bender without sleep)

Re: Incident with Actions and Pages

#266
post #239

Earlier quoted context omitted.

No, monitoring for HTTP response code is a subset of observability and not one that generally gives you the best insights into which subsystems are misbehaving nor why. There are synthetic tests, where you can generate API request calls or even simulate an entire user journey. These allow you to control the user agent, the payloads, and thus you know anything errors back are actual errors. These are triggered by the…

Even a synthetic probe needs a few failures to trigger an alert. You should not alert on cpu, ram, etc

> Even a synthetic probe needs a few failures to trigger an alert.

It doesn't "need" that. That just how most people set it up because it’s an easy sane default that allows for network jitter without inexperienced engineers thinking about different conditions triggering different types of responses.

If you’re measuring internal APIs from an observablity solution that’s has nodes already inside you’re network enclave, then there is a strong argument for alerting early.

> You should not alert on cpu, ram, etc

That’s not true to say as an absolute statement. And a generalisation it heavily depends on the system your monitoring and how it behaves under pressure.

But in any case, I wasn’t suggesting CPU alerts were the end goal. I said:

> these types of metrics are generally bespoke to the type of application your monitoring.

Ie you’ll use metrics but those metrics will be highly specific.

The CPU examples were an illustration as to what a “metric” is (it might seem obvious but not everyone is an expert) but the point was HTTP response codes aren't the only types of metrics one should be capturing and watching.

Re: Incident with Actions and Pages

#269
post #208

Earlier quoted context omitted.

You should never entirely depend on a third party service for deployments. Been burned too many times on that one.

Ok. Move to EC2. Darn AWS is down. Alright, run it on a Mac Mini in your basement. Ahh dawn, your ISP is having issues. Good thing you have a backup 5G hotspot. Ohh no, the power is out. Eventually you have to trust someone else. GitHub is a tragedy of the Commons. Too many people are using it, and Microsoft isn't willing to handle it correctly. Feels like a very good business opportunity. Minimum 50k yearly contract…

It's almost as though GitHub should never have let itself be sold to Microsoft...

Re: Incident with Actions and Pages

#270
post #208

Earlier quoted context omitted.

You should never entirely depend on a third party service for deployments. Been burned too many times on that one.

Ok. Move to EC2. Darn AWS is down. Alright, run it on a Mac Mini in your basement. Ahh dawn, your ISP is having issues. Good thing you have a backup 5G hotspot. Ohh no, the power is out. Eventually you have to trust someone else. GitHub is a tragedy of the Commons. Too many people are using it, and Microsoft isn't willing to handle it correctly. Feels like a very good business opportunity. Minimum 50k yearly contract…

We’re actually moving back to redundant data centres due to all of those problems.

Aggregate risk is too high.

Post reply on HN