lostintranslation lostintranslation - 5 months ago 10x
Node.js Question

Nodejs/express, shutdown gracefully

I have an nodejs server running express to server out http calls. Is there a recommended approach to shutting down the server gracefully if something bad happens? Should I leave the server running somehow?

I.E. on an uncaught exception the server just stops, I think this will kill over connected clients and not hand them back a response.

Should I:

  1. Wait for all http connections to complete before I allow the server to die (and then restart it).

  2. Or should I try and stop the server from ever dieing?

is this proper?

process.on('exit', function () {
console.log('About to exit, waiting for remaining connections to complete');

In this case an error might have been thrown leaving the server in an undefined state and the server will continue to finish up remaining connections.

Is there any good way to handle errors keep running or should I let the server die and restart?


Don't try to do anything fancy with unhandled exceptions. Let the server die.

Generally, if a route handler throws an exception, Express will simply catch it and return a HTTP 500 to the client. Since Express caught the exception, your server will not crash.

What usually happens that brings down a server is when an exception gets thrown inside a callback; for example:

app.get('/foo', function(req, res) {
    db.query(..., function(err, r) {
        throw new Error(); // oops, we'll crash

Because the callback naturally executes outside the Express router call stack, there's no way to associate it with a specific request. However, you can guard against such a situation:

app.get('/foo', function(req, res, next) {
    db.query(..., function(err, r) {
        try {
            throw new Error();
        } catch(ex) {

Express' next function takes an error as its first argument. If you call next with an error argument, it will stop processing routes and look for an error handler, or just return a 500.

Of course, wrapping everything in try/catch is probably overkill; most things don't actually throw exceptions. You should only do this if you know something might throw. Otherwise, you might end up in a very difficult to debug inconsistent state by swallowing exceptions.

It's important to remember that once an unexpected exception is thrown, your application is in an undefined state. It's possible that the problem request will never complete, and your app would never restart. Or any number of other strange things could happen. (Was it a database issue? Filesystem? Corrupted memory?)

These kinds of situations are incredibly difficult to diagnose, much less debug. It's safer and arguably better to just fail fast, crash, and restart the server quickly. Yes, any clients that happen to be connected would get cut off, but it's easy enough for them to simply retry.

If you're worried about availability, use the cluster module so that you have several (usually number of CPU cores) server processes running, and one crashing won't bring the entire site down.