4 ms·

So far its uptime seems comparable to other PaaS services. Curious what opinions HNers have on this is, though: How important is it to have pretty downtime sc

So far its uptime seems comparable to other PaaS services. Curious what opinions HNers have on this is, though: How important is it to have pretty downtime screens, or nothing at all? In this case it's 404-ing, which is inaccurate. Would it be better to just not respond to the HTTP request than to show this? Also have other PaaS services like Heroku got these messages right?

seldo 14y ago
This is one of those perennial problems: if you're spending engineering time making your "we're down" screen look good, you're really optimizing for the wrong thing, but on the other hand, some downtime is unavoidable and you don't want to look unprofessional. An HTTP 500 would definitely be more appropriate in this case, but it seems a 400 is accurate -- it's down because it has somehow forgotten where the apps are (their Twitter stream says a problem with load balancers).
- roberthahn 14y ago
  I know I'm getting in the weeds here but no, 400 is not appropriate -- all 4xx errors indicate an issue with user input (with the possible exception of 418). 5xx errors indicate the problem is occurring on the server side.
  - seldo 14y ago
    Yeah, that's fair. There's some grey area though -- like, if you accidentally delete a file on your site, your server will return 400. How is the server supposed to know it's accidental? So it's accurate (the user has requested a file that doesn't exist) while at the same time being misleading -- the file should be there.
    - roberthahn 14y ago
      I don't see a grey area in that example. I do see a bug tho :) - the server should return 404 (File Not Found) or 410 (Gone). As you say, the server has no way to know whether the file was deleted by accident. A smart server should return 410 if possible. That signals to the user: "Your request was perfect, but the file you wanted is no longer here". If your server returns 404, what it really means is "Hey, your request is fine, I just can't find what you're asking for". A 400 is the "Bad Request" error code; you would typically return this in web API contexts. The message here is "Hey, your request wasn't fine. I don't know what to do with it" If nodejitsu was returning any 4xx errors during its downtime, that's a bug that should be fixed. In this situation, they should have returned either a 500 or a 503, and I'd probably pick 503, and leave 500 to any web apps that suffered an internal error. This way you know that it's not your app but the platform it's running on. As always, the best place to look up the details is in the spec: http://tools.ietf.org/html/rfc2616 http://tools.ietf.org/html/rfc2616 -- long, but quite readable.
phillmv 14y ago
I frankly quite hate it, and no. Depending on the kind of error they're experiencing, Heroku will show a quite unhelpful and generic "Application is down" screen. I know they're limited in what they can show back given a certain kind of error but it's real crappy to let your users or clients hung out to dry. It's especially loathsome with clients because it's indistinguishable from you fucking up. I do wish they showed a "Oh hello we're having a spot of trouble. Please hang tight" instead. Mad points for letting you style the page to match your site. Of course, as a service provider this would not quite be something you spend a lot of time thinking about or optimizing for.

seldo 14y ago

This is one of those perennial problems: if you're spending engineering time making your "we're down" screen look good, you're really optimizing for the wrong thing, but on the other hand, some downtime is unavoidable and you don't want to look unprofessional. An HTTP 500 would definitely be more appropriate in this case, but it seems a 400 is accurate -- it's down because it has somehow forgotten where the apps are (their Twitter stream says a problem with load balancers).

roberthahn 14y ago
I know I'm getting in the weeds here but no, 400 is not appropriate -- all 4xx errors indicate an issue with user input (with the possible exception of 418). 5xx errors indicate the problem is occurring on the server side.
- seldo 14y ago
  Yeah, that's fair. There's some grey area though -- like, if you accidentally delete a file on your site, your server will return 400. How is the server supposed to know it's accidental? So it's accurate (the user has requested a file that doesn't exist) while at the same time being misleading -- the file should be there.
  - roberthahn 14y ago
    I don't see a grey area in that example. I do see a bug tho :) - the server should return 404 (File Not Found) or 410 (Gone). As you say, the server has no way to know whether the file was deleted by accident. A smart server should return 410 if possible. That signals to the user: "Your request was perfect, but the file you wanted is no longer here". If your server returns 404, what it really means is "Hey, your request is fine, I just can't find what you're asking for". A 400 is the "Bad Request" error code; you would typically return this in web API contexts. The message here is "Hey, your request wasn't fine. I don't know what to do with it" If nodejitsu was returning any 4xx errors during its downtime, that's a bug that should be fixed. In this situation, they should have returned either a 500 or a 503, and I'd probably pick 503, and leave 500 to any web apps that suffered an internal error. This way you know that it's not your app but the platform it's running on. As always, the best place to look up the details is in the spec: http://tools.ietf.org/html/rfc2616 http://tools.ietf.org/html/rfc2616 -- long, but quite readable.

phillmv 14y ago

I frankly quite hate it, and no. Depending on the kind of error they're experiencing, Heroku will show a quite unhelpful and generic "Application is down" screen. I know they're limited in what they can show back given a certain kind of error but it's real crappy to let your users or clients hung out to dry. It's especially loathsome with clients because it's indistinguishable from you fucking up. I do wish they showed a "Oh hello we're having a spot of trouble. Please hang tight" instead. Mad points for letting you style the page to match your site. Of course, as a service provider this would not quite be something you spend a lot of time thinking about or optimizing for.