You can set your timer to whatever you want the timeout duration to be for a "stuck" async operation.

Then .unref() the timer. That will keep the timer itself from keeping node.js from exiting so it will exit when all the async operations are done or the timer fires, whichever comes first.

function exit() {
    var t = setTimeout(function() {
        process.exit(1);
    }, 10000);
    // allow process to exist naturally before the timer if it is ready to
    t.unref();
}

You can set your timer to whatever you want the timeout duration to be for a "stuck" async operation.

Then .unref() the timer. That will keep the timer itself from keeping node.js from exiting so it will exit when all the async operations are done or the timer fires, whichever comes first.

function exit() {
    var t = setTimeout(function() {
        process.exit(1);
    }, 10000);
    // allow process to exist naturally before the timer if it is ready to
    t.unref();
}

Something tells me that a more controllable and robust solution would be to code more robustly on each individual async event. The kinds of things that can get stuck like an HTTP request of an external server have their own timeout settings so if you set them, then they will complete one way or the other on their own and you don't run the risk that your external timer might fire before the async operation completes when it wasn't even stuck, but just slow.