[m4rtink]

This was an issue already in the Soviet times, with a couple cases of early rocket explosions destroying the pad and causing long delays, including one spectacular N1 explosion leveling its pad and needing lengthy expensive rebuild.

As a result they went to extensive lengths to avoid pad damage, including never terminating rocket thrust in the first (IIRC) 60 seconds of flight. Better let the rocket crash into something nearby than to explode at the pad.

[mrandish]

> As a result they went to extensive lengths to avoid pad damage, including never terminating rocket thrust in the first (IIRC) 60 seconds of flight.

I was pondering this very thing. Was there a way to learn the same info as this static fire that didn't risk all the pad infrastructure? I get that the tower, fueling systems, deluge, etc all have to work together in a real launch but given the immense schedule and dollar cost of losing the pad, how much less valid would bifurcated tests be? Like each sub-system is tested in-place on the pad without firing the rocket and then static firing itself is done on a more expendable test pad? Maybe even a test pad that's only designed to only survive long enough to get the necessary data before melting and losing the rocket.

Or alternatively, as you mentioned, when it's time to test full fuel load, skip the "static" part and do everything possible to get the rocket up and away ASAP.

[GMoromisato]

The alternative is you don't find out about a problem until it destroys a customer payload. That's better than losing the launch pad, but it depends on the actual probability of each event happening.

What if a static fire reduces your chance of losing a customer payload from 20% to 0.2%, but increases your chance of losing the pad from 1% to 2%?

And note: If they had skipped a static fire and gone straight for a launch, they would have lost the pad anyway, since the explosion happened at ignition.