[simonholroyd]

It's interesting that you'd say the downtime was relatively overwhelming. From an outsider's view HN seems like it must be a relatively low stress site to maintain. If it goes down, YC suffers very little. Its community views the site as a public service. If anything, a few hours or even days of downtime just serves to remind the community how valued that service is (and by extension how positive our feelings towards YC are).

Is there a hidden downside to the downtime I'm missing? Worried it brings into question YC's technical chops?

[pg]

I think almost any programmer running a service used by hundreds of thousands of people would hate the idea of it being down. It's part of building things to want them to work properly.

[simonholroyd]

I certainly sympathize with the stress, I've been there. But programmers are much more effective at resolving downtime in low stress situations, so the best strategy is neutralizing those high-stress moments and just accepting that "downtime happens".

[mcartyem]

Is there anything you believe could have helped avoid HN being down in the way it did?

(Sorry to hijack this post; I doubt you'd see this question in the proper HN downtime post.)

[Donito]

Quote from pg: "For some reason I didn't check the comments after the surgery to see if they were in the right place. I must have been distracted by something."

Short answer to your question: Test the fix after deploying it on production :)

[TheMakeA]

Aside from the obvious HN and YC app services, I believe the office hours scheduling and probably any other internal YC service are all part of the same codebase running on the same server. Sounds like it could be a major problem for them.