5 ms·

> I don't really trust Down Detector, which despite the claims is really People Winging on Twitter Detector. I'm confused. Isn't listening for spikes in compla

> I don't really trust Down Detector, which despite the claims is really People Winging on Twitter Detector. I'm confused. Isn't listening for spikes in complaints about outages a great way to detect them? I know for a fact some service companies monitor social media channels for this purpose (among others). I'd be surprised if that wasn't more or less standard practice. I've checked Down Detector for ISP outages in my area many times now. It's always confirmed them before my ISP did.

Cheer2171 3y ago
The problem is that people use FB login for other sites, and if FB login is down, many users report a problem with that other site, not with FB.
- schrodinger 3y ago
  The point is that the “other site” _is_ down for those who use Facebook to login to it. Maybe they should have a backup password (if they site allows it, f-ing Spotify doesn’t), but it’s still effectively down for them!
noncoml 3y ago
The OP means there is a lot of collateral noise from people who are just tech savvy. Eg. “oh no, I can access Facebook, my internet must be down. Let me login in Down Detector to file a complaint against my ISP”
ceejayoz 3y ago
> Isn't listening for spikes in complaints about outages a great way to detect them? When there's a major ISP outage, people report problems with all the major sites. When Facebook's down, people report problems with any site that has "Login with Facebook" as an option. It's almost never actually an outage impacting all of FAANG at once.
- ImPostingOnHN 3y ago
  > When Facebook's down, people report problems with any site that has "Login with Facebook" as an option. If users log into your site with Facebook, then the login functionality of your site effectively is down when "Login with Facebook" is down. From the user's perspective, your subcontractors, including authentication subcontractors, are a problem for you to deal with and never show them. From your perspective, you could have architected your site in a way that logging in doesn't "go down" when Facebook login is down. If the user chooses "Login with Facebook" over other authentication options available, and they don't want to use other options, educating them with a good error message might help. Or you could remove the Facebook login option, if you (totally reasonably) don't want Facebook's failures to reflect poorly on you.
  - ceejayoz 3y ago
    > If users log into your site with Facebook, then the login functionality of your site effectively is down when "Login with Facebook" is down. There are plenty of sites where "Login with Facebook" is a convenience but hardly the only way to log in. Reddit, for example, has "Login with Google" and "Login with Apple"; it would be highly misleading to claim "Reddit is down" if Google's OAuth flow was having an outage. > educating them with a good error message might help Nothing in the API or OAuth flow would make that doable in an automatic fashion with this outage. It'd have to be something you put up manually as a banner after hearing of the outage. > Or you could remove the Facebook login option, if you (totally reasonably) don't want Facebook's failures to reflect poorly on you. I don't particualrly care; we're talking about why DownDetector isn't necessarily ideal for assessing. It can be a useful signal, in some scenarios, but I've seen plenty of spurious signals come from it.
    - ImPostingOnHN 3y ago
      > Nothing in the API or OAuth flow would make that doable in an automatic fashion with this outage. It'd have to be something you put up manually as a banner after hearing of the outage. That is fair: if I choose to architect my site such that a user-critical feature goes down when a 3rd party service goes down, it behooves me to monitor the 3rd party service and do whatever necessary to properly inform users what's going on. I edited my post unfortunately after you replied, but another option is removing the parts of your site that rely on 3rd parties, if you don't want the failures of those 3rd parties to reflect poorly on you (which they reasonably would). >we're talking about why DownDetector isn't necessarily ideal for assessing. It can be a useful signal, in some scenarios, but I've seen plenty of spurious signals come from it. Indeed, and if a bunch of users say that a feature of your site is down, even if it's a result of a 3rd party failure: chances are, that part of your site is down, and it's partially your fault for relying on a 3rd party for that feature. The users correctly don't care what the root cause is, they expect you to either mitigate it or don't have a feature they rely upon be unreliable.
ldoughty 3y ago
The problem is the source of the reports and display of the reporting. I'd trust Down Detector a lot more if it was filled with Hacker News community -- people who are able to understand that there's "DNS" and "Routing".. and that your phone can have internet access at home while your home PC does not. I personally hate Down Detector's graphing because it can make it 'look' like there's an issue when there isn't really... Facebook with 500,000 reports looked as down as Google with 1,000 reports... For equally sized / used entities, I would not trust that "Google" is down with 1,000 reports. I had a coworker ask me what was going on with the internet because "everything is down.. Facebook, google, gmail, microsoft!" (when seeing the Down Detector home page) DD should normalize the graphs against the service history in some way. A service shouldn't spike because it had 30 reports / hour for a day, then suddenly has 100... when it has a history of being out with 100,000+ reports. The 100 reports are probably mis-reporting, but you can't tell until you dig into each service, one by one, with separate page loads.
cdchn 3y ago
In the Twitter operations area there was a big TV that streamed searches for #failwhale etc. It was actually very useful to detect problems with Twitter by looking for people complaining about Twitter on Twitter.
fmajid 3y ago
Well, Twitter was down for me at least. Google, on the other hand, was not unlike what DownDetector claimed.
EasyMark 3y ago
I think it's a good data point, but it's not a "tell all" indicator. So I agree with you.

Cheer2171 3y ago

The problem is that people use FB login for other sites, and if FB login is down, many users report a problem with that other site, not with FB.

schrodinger 3y ago
The point is that the “other site” _is_ down for those who use Facebook to login to it. Maybe they should have a backup password (if they site allows it, f-ing Spotify doesn’t), but it’s still effectively down for them!

noncoml 3y ago

The OP means there is a lot of collateral noise from people who are just tech savvy. Eg. “oh no, I can access Facebook, my internet must be down. Let me login in Down Detector to file a complaint against my ISP”

ceejayoz 3y ago

> Isn't listening for spikes in complaints about outages a great way to detect them? When there's a major ISP outage, people report problems with all the major sites. When Facebook's down, people report problems with any site that has "Login with Facebook" as an option. It's almost never actually an outage impacting all of FAANG at once.

ImPostingOnHN 3y ago
> When Facebook's down, people report problems with any site that has "Login with Facebook" as an option. If users log into your site with Facebook, then the login functionality of your site effectively is down when "Login with Facebook" is down. From the user's perspective, your subcontractors, including authentication subcontractors, are a problem for you to deal with and never show them. From your perspective, you could have architected your site in a way that logging in doesn't "go down" when Facebook login is down. If the user chooses "Login with Facebook" over other authentication options available, and they don't want to use other options, educating them with a good error message might help. Or you could remove the Facebook login option, if you (totally reasonably) don't want Facebook's failures to reflect poorly on you.
- ceejayoz 3y ago
  > If users log into your site with Facebook, then the login functionality of your site effectively is down when "Login with Facebook" is down. There are plenty of sites where "Login with Facebook" is a convenience but hardly the only way to log in. Reddit, for example, has "Login with Google" and "Login with Apple"; it would be highly misleading to claim "Reddit is down" if Google's OAuth flow was having an outage. > educating them with a good error message might help Nothing in the API or OAuth flow would make that doable in an automatic fashion with this outage. It'd have to be something you put up manually as a banner after hearing of the outage. > Or you could remove the Facebook login option, if you (totally reasonably) don't want Facebook's failures to reflect poorly on you. I don't particualrly care; we're talking about why DownDetector isn't necessarily ideal for assessing. It can be a useful signal, in some scenarios, but I've seen plenty of spurious signals come from it.
  - ImPostingOnHN 3y ago
    > Nothing in the API or OAuth flow would make that doable in an automatic fashion with this outage. It'd have to be something you put up manually as a banner after hearing of the outage. That is fair: if I choose to architect my site such that a user-critical feature goes down when a 3rd party service goes down, it behooves me to monitor the 3rd party service and do whatever necessary to properly inform users what's going on. I edited my post unfortunately after you replied, but another option is removing the parts of your site that rely on 3rd parties, if you don't want the failures of those 3rd parties to reflect poorly on you (which they reasonably would). >we're talking about why DownDetector isn't necessarily ideal for assessing. It can be a useful signal, in some scenarios, but I've seen plenty of spurious signals come from it. Indeed, and if a bunch of users say that a feature of your site is down, even if it's a result of a 3rd party failure: chances are, that part of your site is down, and it's partially your fault for relying on a 3rd party for that feature. The users correctly don't care what the root cause is, they expect you to either mitigate it or don't have a feature they rely upon be unreliable.

ldoughty 3y ago

The problem is the source of the reports and display of the reporting. I'd trust Down Detector a lot more if it was filled with Hacker News community -- people who are able to understand that there's "DNS" and "Routing".. and that your phone can have internet access at home while your home PC does not. I personally hate Down Detector's graphing because it can make it 'look' like there's an issue when there isn't really... Facebook with 500,000 reports looked as down as Google with 1,000 reports... For equally sized / used entities, I would not trust that "Google" is down with 1,000 reports. I had a coworker ask me what was going on with the internet because "everything is down.. Facebook, google, gmail, microsoft!" (when seeing the Down Detector home page) DD should normalize the graphs against the service history in some way. A service shouldn't spike because it had 30 reports / hour for a day, then suddenly has 100... when it has a history of being out with 100,000+ reports. The 100 reports are probably mis-reporting, but you can't tell until you dig into each service, one by one, with separate page loads.

cdchn 3y ago

In the Twitter operations area there was a big TV that streamed searches for #failwhale etc. It was actually very useful to detect problems with Twitter by looking for people complaining about Twitter on Twitter.

fmajid 3y ago

Well, Twitter was down for me at least. Google, on the other hand, was not unlike what DownDetector claimed.

EasyMark 3y ago

I think it's a good data point, but it's not a "tell all" indicator. So I agree with you.