My experience:<p>- uncaught exception should terminate the process... but<p>- cluster.js allows restating failed processes easily<p>- and you whole cluster should be restarted if it dies (we use upstart&#x27;s respawn)<p>- uncaught exceptions should be real exceptional situations and bugs only, never applicative exceptions (it would be a bug)<p>- have the cluster master send your team an email as soon as a process dies, to maintain awareness (we use Slack notification + email)<p>- kill bugs, aim for 0 failures. Invalid parameters should never kill your app. An unreachable DB could, because reconnecting can be difficult, and may not succeed<p>With this:<p>- when unexpected failure happens (bugs mostly), you know it didn&#x27;t kill your whole app (a single process dies)<p>- your cluster could loop trying to restart the app with repeated failures, and it could work and restore your app. If it doesn&#x27;t, you&#x27;ll be flooded in emails and you&#x27;ll be aware of the gravity of the problem. Networking problems are often solved this way in a few seconds<p>- you will kill bugs, because of the awareness factor of emails<p>- and you&#x27;ll have an incentive to keep your app startup time low<p>That&#x27;s how we do it.