Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Outage

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 87 posts

Re: GitHub Outage

#41

Post by smt88 »

naikrovek wrote: post #29
adamscybot wrote: post #11

Earlier quoted context omitted.

In my experience its often the case the status site does not reflect reality -- until someone intervenes.

that's the whole point of a manually updated status page. you don't want automation to update it because that automation can fail. automation likely caused the outage you want to know more about. you also don't want your automation guessing at what the problem is, or what the effects are. you want real info from a real person even if it isn't given to you the millisecond you look for it. this is why status pages aren…

This is so wrong that it makes me wonder if it's satire.

"The whole point" (as you put it) of status pages was to publish high-level monitoring data to users. The monitoring process should occur outside the system that is being monitored, perhaps even on a different cloud.

Eventually, many companies realized this revealed expensive SLA violations and ended that level of transparency.

Your status page can and should report import metrics to users, like elevated error rates. Most status pages used to.

Re: GitHub Outage

#44

Post by mejutoco »

naikrovek wrote: post #29
adamscybot wrote: post #11

Earlier quoted context omitted.

In my experience its often the case the status site does not reflect reality -- until someone intervenes.

that's the whole point of a manually updated status page. you don't want automation to update it because that automation can fail. automation likely caused the outage you want to know more about. you also don't want your automation guessing at what the problem is, or what the effects are. you want real info from a real person even if it isn't given to you the millisecond you look for it. this is why status pages aren…

IMO the reason status pages are not updated automatically is legal. SLA and other legal contracts might change if every time something is down the status page reflects that accurately, so people try to hide it.

Approached in that way a status page is almost useless, since it is not reliable and only after I found out via other sources it is updated.

I am perfectly happy with a status page that shows the, mm, status of the service. Could be as easy as not reachable, slower than usual or any generic information (a traffic light). I disagree that a status page has to show the why of the error, although of course it would be nice.

Re: GitHub Outage

#45

Post by smt88 »

MattIPv4 wrote: post #30
adamscybot wrote: post #11

Earlier quoted context omitted.

In my experience its often the case the status site does not reflect reality -- until someone intervenes.

Exactly, status pages tend to be updated by the humans responding to the incident, they're not automatic (that'd be pretty useless, you already know it's down, you want to know when they know it's down). Coordinating what to put on the status page when an incident happens can take time, getting the correct scope of impact from responding engineers etc.

"Humans responding to the incident" is what Twitter and email communications are for. Status pages are supposed to be realtime status, and they should show downtime as soon as users suspect it.

As a user, you often don't know if the vendor's system is really down or if there's something wrong with your own system.

Re: GitHub Outage

#46

Post by deepstack »

adamscybot wrote: post #11
omn1 wrote: post #2

Even though the status page ( https://www.githubstatus.com/ ) shows no issues, I'm still getting the occasional 500. It seems to be happening quite irregularly. They are possibly facing a lot of load.

In my experience its often the case the status site does not reflect reality -- until someone intervenes.

from the message I'm getting it seems like the load balancer is not able to spawn up server to handle new connections. Again, status page needs to reflect that, which means the status server page is NOT running on the same infrastructure as the main server group. Stop using AWS(or whatever fill in the blank hosting provider) for the status and production environments.

Re: GitHub Outage

#48

Post by irajdeep »

qwertox wrote: post #7

I haven't pushed to GitHub in over a year. Now I'm setting up a new page on github.io with a new repo and GitHub goes 500 just when I try to push. Those GitHub badges... they are as ugly as it gets.

> Those GitHub badges... they are as ugly as it gets.

Bingo. Not everything in this world needs to be gamified.

Re: GitHub Outage

#49

Post by XCSme »

MattIPv4 wrote: post #33
bowsamic wrote: post #14

Earlier quoted context omitted.

Status pages are absolutely useless. I've never seen them accurately reflect an outage

You are missing the point of a status page. They're not automatic things that tell you instantly when something is down -- that'd be pretty pointless, you already know it's down. They're updated by the folks responding to the incident, so you know they know there's an issue and that they're looking into it.

> that'd be pretty pointless, you already know it's down

How would I know? What if my website doesn't have any monitoring and I use a payment system, shouldn't I automatically be notified when that payment system is down? What if it's down for a week? I think service-providing companies should always announce outages and even suspected outages.

Re: GitHub Outage

#50

Post by ramigb »

maxcan wrote: post #15

Github outages are the bored engineer's equivalent of getting a surprise snow day when you were in school, full of unbridled joy. For engaged, happy engineers its the equivalent of getting a surprise snow day when you are grown up and have to go dig your car out of the snow and its a normal day just with extra steps.

I can be both bored and engaged, don't test me buddy /s
Post reply on HN