In a database driven web app, what should the user see when the database is unavailable?

If a web application relies on a database to serve dynamic content and that content is unavailable for whatever reason (database server down, etc.), what is the preferred method for handling this scenario?

1. Redirect the visitor to a custom 404 page?
2. Display the page anyway but include some sort of error message where the content would otherwise be?
3. Display a related page that has sta开发者_Python百科tic content?
4. Other?

I understand that proper error logging should occur as well as notifying the webmaster and/or sysadmin. I'm mostly interested in best practices for what the end user should see in this situation.

#3 if you can (e.g. a snapshot of dynamic content taken every 20 mins), but make it crystal clear that it's static content as of <time> and will be refreshed as soon as system issues are resolved.

#2 if you can not, as long as the error is human readable and not a literal re-print of an exception's stack trace from Java or somesuch.

Whatever you do, DON'T return a 404 - your application may not be working properly, but you don't want to give the impression that the URL is incorrect. Aside from anything else, this could have a negative impact on your site's SEO.

If you're going to return some HTTP status other than 200, then I'd recommend a 503 "Service Unavailable" response. This is more indicative of a temporary fault with the application, rather than something being wrong with the the HTTP request.

I think that depends on how tied to the database the content of the entire page is. For example, in our web apps, if the database is down then there's no method of authentication; our only resort would be a custom error screen to the effect of 'We're having problems now; stop by again later'.

Now; if the dynamic content is similar to a quote of the day on top of a mostly static file, then a simple error message in place of content; or omission of dynamic content all together would be appropriate.

So; it depends on what service the page provides, and whether or not it can provide anything useful without the backend.

I think #3 is probably the best, but not always feasible. If that's not possible, some sort of "Technical difficulties, Please stand by..." might be best (obviously, you can change the wording to something better). Just avoid actually printing ERROR: ERR_123/SIGSEGV! (or something like that) in big red letters. It makes users think your app is broken and they may not come back.