The weight of the propellant helps hold the rocket on the pad during the test fire, reducing how much force the hold-downs need to exert to keep the rocket on the pad, and stressing the rocket's structure in the same way it will be stressed at launch.
Test fires with a near-empty rocket would put considerably more force on the pad's hold-downs and the corresponding parts of the rocket's structure.
Blue also had a fuelled 2nd stage on top of the booster for the static fire, which is not out of the ordinary.
SpaceX has a "cap" that is held down with cables that it uses when it needs to test-fire a first stage by itself at its McGregor test site; static fires at launch sites are usually done with the 2nd stage on top.
Right. The forces these things produce are massive. I only know the specifics for the Space Shuttle, but when it is at full liftoff thrust (liquid and solid boosters) there's just no way to keep it leashed to Earth. It's going up whether you want to or not.
The space shuttle stack has a net thrust (thrust minus weight) of about 9 MN at lauch [1]. High carbon steel has a yield strength of 700 MPa [2]. So you need a piece of steel with a cross section of 0.013 square meter to hold it down. That's a rod 6.5 cm / 2.5 inches in diameter. Hardly impossible. Your nearest road suspension bridge probably has cables bigger than this.
If you want to argue that it's impossible in practice, I'll point out that SpaceX's Starship first stage has a net thrust of 53 MN [3], and it does static fires (without the weight of the second stage on top) [4].
The space shuttle didn't do static fires because of the solid rocket boosters that would need to be teared down and reconstructed afterwards; not because it's physically impossible to hold it down.
In September 2016 almost exactly the same thing happened to a Falcon 9 at the Cape, also on a static fire. New Glenn is bigger, so bigger bang, but pretty much exactly the same thing.
Off the top of my head, I recall in SpaceX's case it was a helium tank failure- a helium tank weld failed and the helium tank itself shot through the cryogenic oxygen, hit the far wall, and gave off a spark. But that sort of failure is only apparent when everything is pressurized correctly, which means tanks have to be full. The goal of the test is that you detect that sort of failure before it goes boom and then can fix it.
Wasn't a bad weld; it was a bad interaction between liquid or solid oxygen and what were previously thought to be inconsequential defects in the composite-overwrapped pressure vessel the helium was loaded into.
Quoting from one of the press releases:
"The recovered COPVs showed buckles in their liners. Although buckles were not shown to burst a COPV on their own, investigators concluded that super chilled LOX can pool in these buckles under the overwrap. When pressurized, oxygen pooled in this buckle can become trapped; in turn, breaking fibers or friction can ignite the oxygen in the overwrap, causing the COPV to fail. In addition, investigators determined that the loading temperature of the helium was cold enough to create solid oxygen (SOX), which exacerbates the possibility of oxygen becoming trapped as well as the likelihood of friction ignition.
"The investigation team identified several credible causes for the COPV failure, all of which involve accumulation of super chilled LOX or SOX in buckles under the overwrap."
Was that when a SpaceX engineer demanded immediate "roof" access to ULA's pad because they suspected someone at ULA had used a sniper rifle to shoot at the Falcon? Crazy times.
>Externally, they sent the site director for their Florida operations, Ricky Lim, to inquire whether he might visit the roof of the United Launch Alliance building... ULA told SpaceX’s Ricky Lim to get lost when he wanted to see the roof of their building in Florida.
> This theory appealed to SpaceX founder Elon Musk, who was asleep at his home in California when the rocket exploded. Within hours of hearing about the failure, Musk gravitated toward the simple answer of a projectile being shot through the rocket.
Man, the signs were always there, right? I think I only fully realized it in 2018 during the cave "incident".
I think this makes sense, but then what’s the learning - dont make bad welds? I imagine they were already trying to do as best they could. Or perhaps “however stringent you think your checks are, they need to be more stringent”. And then learning that repeatedly is somewhat spectacular.
There's another comment that it wasn't the weld but even if it was the welders would build to spec and "better" (if it's known what better is) only if it's straightforward. There are certainly scenarios where a fabricator could design a better jig or use a more precise process but if the spec doesn't call for it then it's probably not going to happen because there are also the dimensions of time and money that matter as well.
I don't know anything about this particular launch, but one reason static fires sometimes load more fuel than you'd think is that the hold-down clamps aren't rated for the total thrust of the vehicle. Launch thrust is usually 1.2-1.6x the launch weight (if it's <1x you will not go to space today), so after subtracting gravity you've got 0.2-0.6x the weight acting upwards on the clamps. But rockets are mostly fuel by weight, so if you static fire it nearly empty, then that gravity term goes to ~zero, and the clamps have to hold the full 1.2-1.6x. You could overbuild them to handle that -- which isn't the end of the world, because they don't need to fly -- but it can be easier to just add extra fuel and detank it afterwards.
I don't know if it'd be a factor for BO, but doesn't the ignition sequence sometimes use gravity feed to begin with, before the turbo pumps kick in, with the height of the fuel tanks meaning that full tanks add a few atm of pressure. Therefore, a test without full tanks isn't exactly replicating the normal ignition sequencing conditions.
You've got two large tanks making up the bulk of the stage's structure - one for oxidizer, one for fuel. They have large diameter pipes that feed propellant to the engines. You can't mix the ballast with either the oxidizer or fuel, and you can't feed the engines from anywhere but the propellant tanks...
If you are writing an integration test for some new and potentially bug-ridden code then you might opt to mock, say, the database connection.
Doing so risks having to write so much database logic — with all the potential for getting that code buggy as well — that it’s often better to avoid the mock and test the entire system, end-to-end.
The vehicle is designed to hold all that fuel, plus whatever payload it carries on top, but it's not designed to have heavy loads attached to it in any other way. Rockets are so intensely optimized for weight that sometimes they're barely strong enough to stand upright if you fuel them the wrong way: https://www.youtube.com/watch?v=imkdz63agHY.
That's a great video! Thank you for sharing it. A rocket is more like a soda can than a building but it's hard to relate when you see such a massive object!
You can see a similar effect after the explosion at the end of last week's Starship test flight. If you look at where the flames are coming out after the first fireball clears, it kind of pancakes under its own weight there: https://www.youtube.com/live/Zi2SU98BAD8?t=5735s
Oh huh. You really can. I didn't pick up on that the first few hundred times I watched it. That's really cool. It kind of splats down into a 2-d rectangle.
It's been said that the most amazing engineering of the whole Shuttle program was the external fuel tank (and there is one with the static display of Endeavour here at the California Science Center in LA).
You don't need to fill it all the way up for that. If in flight your engines burn for 2 minutes, but your static fire is only a few seconds you can see why.
singleflight and sync.Once handle slightly different use cases.
sync.Once - Run exactly once, only the first call is invoked.
singleflight - Merge concurrent requests into one request and return the response to all the callers.
Where I tend to use both, is sync.Once tends to get used for lazy init code, the first caller does any client initializations, and subsequent callers wait, and then the lazy init is done and never done again in the lifetime of the application.
For singleflight, it tends to be on merging relatively expensive requests together. Like retrieving and parsing a JSON object from a server in concurrent requests. Merging those requests together, doing the expensive work once and distributing the results to each concurrent caller type of idea. With the results becoming invalid over time so a later set of requests need to do it all over again.
sync.Once is for performing lazy initialization once in a process' lifetime. This is for duplicative requests for the same resource. E.g. concurrent requests for the same cache key can be coalesced into a single call. You can use this to prevent the connection setup thundering herd that often occurs when a bunch of requests come in for the same destination with an empty connection pool, etc.
Using profanity indicates a weak vocabulary. A lack of discipline. A degree of unrefinement unbecoming of astronauts representing the "best" of humanity and their country.
Depending on the type of profanity it can divide societies by reinforcing social schisms/prejudices. Such words typically cluster around areas of cultural discomfort such as religion, sex, and hygiene, causing polarizing emotional reactions. It's biological as well as cultural.
Seems like the "best and bravest humanity has to offer" can probably represent a little better than that for one of the most significant feats of history.
If you think astronauts are supposed to be "the best of humanity" then you are going to be dissapointed. Astronauts are chosen because they can withstand high G forces and keep cool under pressure. It is very similar to how race car drivers are chosen. No one believes formula 1 drivers are "the best of humanity". And I wouldn't care if astronaut cursed anymore than if a formula 1 driver did.
That’s absolutely not true. Watch any F1 race and within the first few minutes you will hear a censored drivers radio. IIRC F1 tried to penalize drivers who swore too much on the radio and faced massive backlash from the drivers
> Using profanity indicates a weak vocabulary. A lack of discipline. A degree of unrefinement unbecoming
Says you. I think not swearing obviously indicates a weaker vocabulary since there's a lot of things you can't or won't say.
Of course, swear words can be offensive if you're their target, and I don't really enjoy that side. But they are _very_ effective in communicating frustration, anger, surprise. I think using them brings a bit of spice to life and a well placed "Fuck!" can feel extremely cathartic and... dare I say... pleasant.
> Using profanity indicates a weak vocabulary. A lack of discipline.
Lack of discipline, maybe. Though that is subjective.
Weak vocabulary, no, that is objectively not true unless someone is repeatedly using a small number of profanities (i.e. someone who uses the F/C bombs and the N & R words, for instance). Studies of online communications have shown the people who use a range of profanity also have a wider vocabulary more generally, wider on average even than those who were not seen to use profanities at all.
Of course this still has some subjective judgement involved: the studies had to define what was considered profane, and may have missed many words only considered bad in a minority of places. I'm not sure what the studies did, if anything, to account for people speaking the target language as a second that they are not fluent in. These could be important factors in correctly defining the “doesn't use them” set.
> It's biological as well as cultural.
Only because there is a biological component to the reaction to the words, which is trained by culture. This could be a programmed disgust reaction, an amused one (a small rush of relevant endorphins), or a fear reaction (where the word is a slur that is often followed by further problems like the threat of physical violence). The closest we come to a truly biological reaction might be words associated with excreta and so forth, the things they can describe carrying a biological risk, but even that is culturally informed (you aren't born knowing that shit means a form of feculence, or that feculence is considered a more polite way to describe something dirty to the point of being unsafe).
Sorry, using Sacré Quebecois or Mexican albures is a total art form which requires extensive knowledge and creativity. Nothing further from “a weak vocabulary”.
i'll bet you $1000 my vocab is wider, deeper, and more sophisticated than yours despite my profuse use of profanity. interested? happily able to provide various standardized tests (SAT/GRE/LSAT/etc.) and/or your preferred method (wordle/crossword/etc.).
That's just regurgitating the same Puritannical bullshit that's been infecting American society for the past hundred years or so.
Humans curse sometimes. That's what happens to real people in the real world. Astronauts are not some kind of pure, unspoiled demigods. They're regular-ass humans who say things like shit and fuck. Just like approximately everyone else does.
I'd rather the best and brightest among us admit that they're real people just like everyone else than put on a show to protect the delicate sensibilities of a very small number of people who clutch pearls and scream when someone nearby says a "bad word".
Astronauts are people. They have genitals, they walk around nude sometimes. They shit, piss, and fuck just like you and me. You want to deify and make them into false idols for some reason. That is a fundamentally bad and wrong thing to do, and you can directly quote many/most religions on that one.
It has been pretty rough. Their own numbers report just a single `9` for Actions in Feb 2026 with 98% uptime. But that said -- I don't get the 90% number.
Anecdotally, it seems believable that 1 in 50 times (2%) in Feb that Actions barfed. Which is not very nice, but it wasn't at 1 in 10 times (10%).
It looks like the aggregate stats are more of a venn diagram than an average. So if 1/N services are down, the aggregate is considered down. I don't think this is an accurate way to calculate this. It should be weighted or in some way show partial outages. This belief is derived from the Google SRE book, in particular chapters 3 (embracing risk) and 4 (service level objectives)
If you're using all services, then any partial outage is essentially a full outage.
Of course, you can massage the numbers to make it look nicer in the way you described but the conservative approach is better for the customers.
If you insist, one could create this metric for selected services only to "better reflect users".
That being said, even when looking at the split uptimes, you'd have to do a very skewed weighting to achieve a number with more than one 9.
As a “customer”, I consider github down if I can’t push, but not down if I can’t update my profile photo (literally did this today, sending out my github to potential employers for the first time in a long time). This stuff is notoriously hard to define
Thinking back to when I was hosting, I think telling a customer "your web server was running fine it's just that the database was down" would not have been received well.
I mean I think it's useful. It answers the question, "what percentage of the time can I rely on every part of GitHub to work correctly?". The answer seems to be roughly 90% of the time.
Nobody cares about every part of GitHub working correctly. I mean, ok, their SREs are supposed to, but tabling the question of whether that's true: if tomorrow they announced a distributed no-op service with 100% downtime, you should not have the intuition that the overall availability of the platform is now worse.
An aggregate number like that doesn’t seem to be a reasonable measure. Should OpenAI models being unavailable in CoPilot because OpenAI has an outage be considered GitHub “downtime”?
The third-party aspect is irrelevant, but while high downtime on any product looks bad for the company and the division, I consider GitHub Copilot an entirely separate product from GitHub, and GitHub Copilot downtime doesn't interfere with my use of GitHub repos or vice versa, so I'd consider its downtime separately.
GitHub Actions, on the other hand, is frequently used in the same workflows as the base GitHub product, so it's worth considering both separately and together, much like various Azure services, whereas I see no reason at all to consider an aggregate "Microsoft" downtime metric that includes GitHub, Azure, Office 365, Xbox Live, etc.
The most useful, metric, actually, is "downtimes for the various collections of GitHub services I regularly use together", but that would obviously require effort to collect the data myself.
My use of GitHub is like yours; I depend on Actions, but I couldn't give less of a damn about Copilot. However, Microsoft has tried to get people to adopt Copilot-heavy workflows, where Copilot plays an integral part in the pull request review process. If your process is as Microsoft pushes for -- wait for Copilot to comment, then review and resolve the stuff Copilot points out -- then Copilot being down means you can't really handle pull request, at least not in accordance with your standard process. For people who embrace Copilot in the way Microsoft wants them to, a GitHub Copilot outage has a serious impact on their GitHub experience.
I don't think that's a fair comparison. Google Maps, Google Calendar, Google Drive, Google Search, Google Chrome, Google Ads, etc. are all clearly completely different products which have very little to do each other, they're just made by the same company called Google.
GitHub is a different situation. There's one "thing" users interact with, github.com, and it does a bunch of related things. Git operations, web hooks, the GitHub API (and thus their CLI tool), issues, pull requests, Actions; it's all part of the one product users think of as "GitHub", even if they happen to be implemented as different services which can fail separately.
EDIT: To illustrate the analogy: Google Code, Google Search and Google Drive are to Google what Microsoft GitHub, Microsoft Bing and Microsoft SharePoint are to Microsoft.
Completely agree, it makes it worse actually as Github's secondary functions so to speak are things we implicitely rely on.
When I merge to master I expect a deploy to follow. This goes through git, webhooks and actions. Especially the latter two can fail silently if you haven't invested time in observation tools.
If maps is down I notice it and immediately can pivot. No such option with Github.
It depends, for example - I would consider Google Drive uptime as part of say Google Docs’ overall uptime because if I can’t access my stored documents or save a document I’ve been working on for the past 3 hours because Drive is down I would be very pissed and wouldn’t care if it’s Drive or Docs that is the problem underneath I still can’t use Google Docs as a service at that point.
From the point of view of an individual developer, it may be "fraction of tasks affected by downtime" - which would lie between the average and the aggregate, as many tasks use multiple (but not all) features.
But if you take the point of view of a customer, it might not matter as much 'which' part is broken. To use a bad analogy, if my car is in the shop 10% of the time, it's not much comfort if each individual component is only broken 0.1% of the time.
> But if you take the point of view of a customer, it might not matter as much 'which' part is broken. To use a bad analogy, if my car is in the shop 10% of the time, it's not much comfort if each individual component is only broken 0.1% of the time.
Not to go too out of my way to defend GH's uptime because it's obviously pretty patchy, but I think this is a bad analogy. Most customers won't have a hard reliability on every user-facing gh feature. Or to put it another way there's only going to be a tiny fraction of users who actually experienced something like the 90% uptime reported by the site. Most people are in practice are probably experienceing something like 97-98%.
Sorry, by 'customer' I meant to say something like a large corporate customer - you're buying the whole package, and across your org, you're likely to be a little affected by even minor outages of niche services.
But yeah, totally agree that at the individual level, the observed reliability is between 90% and 99%, and probably toward the upper end of that range.
A better analogy is if one bulb in the right rear brake light group is burnt out. Technically the car is broken. But realistically you will be able to do all the things you want to do unless the thing you want to do is measure that all the bulbs in your brake lights are working.
That's an awful analogy because "realistically you will be able to do all the things you want to do". If a random GitHub service goes down there's a significant chance it breaks your workflow. It's not always but it's far from zero.
One bulb in the cluster going out is like a single server at GitHub going down, not a whole service.
These are two pages telling two different things, albeit with the same stats. The information is presented by OP in a way to show the results of the Microsoft acquisition.
Or they’re just offline, because their backup batteries only last a few hours, and the gensets for the backhaul have run out of diesel. Iberian blackout last year, I didn’t even know it had happened until I went to pick the kid up from school - just another day at the home office.
This too depends on which POP/ground station you're landing at.
Maybe less so once the majority of starling satellites are capable of laser communications to route your traffic down to a less saturated ground station.
And yet, try getting a full backup of your Google phone onto your own computer. (Without rooting/wiping the whole thing.) Heck, try getting just your text messages off (without a separate app)!
You can't. (Last time I checked.) The backup is encrypted in the cloud, and the only way to download it is to restore it to a phone.
Whereas I can just plug in my iPhone and get a full backup, complete with sqlite manifest, completely accessible. Text messages, photo library, everything.
I know a WDR typically would, but I don't think they perform an ignition for those.
reply