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.
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.
