Most status pages seem to be hosted on the same infra they're monitoring, so they tend to go down with the ship, while visitors are greeted by a conveniently cached "all green" version of the page.
Not surprising when one realizes that status pages, by necessity, become marketing tools.
I had the same feeling. When my PRs started failing, a few mins later I went to the status page and got immediate feedback that they were aware of it. That was useful.
I haven't seen "on crack" used in a positive light, but apparently it is sometimes? Usually I'd say "they must have a crack team on incident response", meaning a highly functional, smooth-running team.
Huh, I swear I heard in a positive context before. But English in not my native language, so my feel on the nuance of this expression is probably a bit off.
There's a subtle distinction. "Like ... on crack/steroids" means a really good / fast version of something (I think steroids is probably the more common variation) e.g. "an e-bike is like a bicycle on crack". "They're on crack" means "They are crazy".
Yeah "on crack" usually means they're not right in the head.
In this context though, OP is referring to the drug where the Github engineers are being quick/energetic about fixing the issue because they're "boosted" by the drug's effects.
Yes, they obviously meant the more common, positive associations related to methamphetamines like, "great job on that quick PR, Kim. You must be on meth!" :)
> To be crack -- as in "a crack shot" or "a crack team of commandos"
To explore the quirks of English grammar a bit further... While "the general expected this to be a crack team of commandos" flows fine, I've never seen "the general expected this team to be crack".
Perhaps it's similar to the rules for the adjective "top"? One can have a "top team of athletes", but "this team of athletes is top" doesn't work, it needs to be "topmost" or something.
IANAGrammarian, but it's almost as if "crack" isn't being used as adjective that modifies "team", but instead they've merged to become a single noun of "crack-team"... kind of like how "first-responder" is a category of emergency-related jobs rather than literally any person who happens to be the first to arrive.
No its not. Cracked is a term which is usually used in gaming. The term "on crack" is used to denote someone who is on very high energy like someone on literally crack the drug.
this is offset by taking your job slightly seriously when implementing gh actions for your org by understanding how they're resolved and pinning them to commit SHAs, like how github themselves recommend under their basic security guide
after hearing similar stories from frontend developers who haven't even heard of "npm ci" or use range pinned dependencies on production systems, im almost never going to be sympathetic on blaming the package maintainers over developer ignorance following basic security guidelines
Sure, but then again the link you sent says: `Pin actions to a tag only if you trust the creator`
If I don't trust GitHub, why am I storing my source code on it and running CI via GitHub actions?
There are also some security gains from ranged pinning. Suppose I pin my library to `1.1.x` instead of `1.1.0`, when a security patch comes along for some CVE, my service will automatically run the `1.1.1` patch release the next time we deploy it.
I would say the likelihood of a developer getting lazy and not bumping a dependency causing a security incident is higher than a supply chain attack if you're already using reputable libraries.
Let's be frank, how many developers care enough to go into the 10 repos they've ended up owning to go and change their `actions/checkout@v3.1.6` to `actions/checkout@v3.1.7`.
Didn't notice it this time! At work we use bitbucket, and for the last few weeks I've been hacking on a hobby project on a 37 year old Mac. It can't run Git, but it does have Amend[1]!
They are just honest about reporting these events. Others don't, so they look better. It's easy to lie without getting caught, because most people don't experience most outages personally.
If this was Twitter / X having these outages every single week, the entirety of HN would come out and scream 'Twitter / X falling apart!', 'It is crumbling', 'Its grinding to a halt again!'
In comparison to GitHub which for a service to have tons of outages a week is quite atrocious for reliability.
But somehow it is acceptable to tolerate GitHub's ridiculous uptime record, but of course, on HN and in wider tech circles, a different standard of uptime is applied here to GitHub despite it being known that it has fallen over much more times than Twitter / X has done for years, week after week.
Until the next time GitHub goes down again. Probably won't be long anyway.
> If this was Twitter / X having these outages every single week, the entirety of HN would come out and scream 'Twitter / X falling apart!', 'It is crumbling', 'Its grinding to a halt again!'
Fail Whale is a thing tho, remarkable for frequent sightings in the seas of Twitter.
If Twitter / X went down every week like GitHub is currently doing for years, they would be called out for that, immediately. But here we have GitHub; a centralized service having over 100M+ active users and their record of uptime is far worse than Twitter / X's and it is given a pass each time it falls over every week.
By that standard, we should not be accepting GitHub's ridiculous uptime history and it has been found that GitHub is far more unreliable than most services including Twitter / X but somehow right here, GitHub is not falling apart or seen as unreliable, especially with having more than 5 incidents in one month for years?
Eh, that's giving MS too much credit. They're as honest as most corporations are with status pages. I've experienced outages and error pages many times while the status page showed green across the board.
There's definitely been a noticeable decrease in reliability since MS took over. They've introduced many features, which is appreciated, but products like Actions are notoriously unreliable and flaky.
Lots of attrition of good engineers. Management is not held accountable for failures, only engineers are scapegoated. As a result, remaining engineers are disgruntled and don't care.
> Blind is an echo chamber, and attracts a certain type of person, for sure.
It certainly is a misery-loves-company community. But I have found them to be the most honest representation of a company and its tech and management practices. It is also a reliable source of compensation data.
For example, I look at Meta's reviews there and that matches my experience. Nobody cares about their apps. All people care about is performance reviews with fake impact. That was exactly my experience in the company.
I've found its accurate for Meta / Microsoft / Google / Apple / Netflix / Amazon. Having worked at Apple for half a decade, it seemed (mostly) accurate.
I have found it less accurate for other companies that are big and desirable but not nearly as sought after to work for in the last decade. For startups or smaller companies, its not the best data point
Don't know where I'd put GitHub, maybe the signal to noise ratio is closer to one of the big companies than not, however my current employer has a Blind channel and its not very accurate to my experience
Lol! If you're an engineer and you don't spend even a little time on Blind, you're signing up to get hustled. Learned so many interesting tidbits from Blind that I was able to use to get ahead in my career. Is it negative, yes; can you still benefit from it, yes.
Businesses that can turn profit from monkeys as employees are best businesses. Running such businesses on tightly standardized PhDs is best for its own survival. So that's what everyone does to various degrees, and it's also such a horrible thinking.
Only partially I believe, there quite famous for running their own hardware (metal cloud). I think some new features like Actions, Codespaces and of course Copilot run on Azure.
Github is down a few hours per month but it has never lost data. Work doesn't grind to a halt because your git host is down. So really, Github still provides a lot more value than self hosting.
But sure, keep evangelizing and talking down to people who prefer it to self-hosting, I'm sure it will accomplish your goal.
> Work doesn't grind to a halt because your git host is down.
When you cannot push your critical change to master on GitHub or run your GitHub Action, then it does grind work to a halt, as it has done with the many commenters here.
> So really, Github still provides a lot more value than self hosting.
Centralizing everything to GitHub is much more riskier than self-hosting given the number of times GitHub has fallen over or had an 'incident'.
> But sure, keep evangelizing and talking down to people who prefer it to self-hosting, I'm sure it will accomplish your goal.
My point is self-proving every month and week that something in GitHub goes down or has an incident. I'll be expecting you to complain again once it falls over in a month's time at the latest.
I've been an incident responder where the incident was, "We promised a customer that changes would go out today, but GitHub is down, and thus our CI/CD is also down."
earlier this year, a team i'm no longer a part of switched from using AWS CodeCommit to using GitHub. at the time, i questioned why switch to something that goes down a lot. the response was it never goes down. the next week, outage. there was no valid reason on why switching to github other than "some potential VC questionnaire asked if the company was using github". i'm much happier no longer being there when these kinds of red flags are replaced with klaxons