ある、すなわち即座に起動・終了することができる。対する変更の素早いデプロイを容易にし、本番デプロイの堅牢性を高める。よう努力するべきである。理想的には、1つのプロセスは、起動コマンドが実行されてから数秒間でリクエストやジョブを受け取れるようになるべきである。起動時間が短いと、リリース作業やスケールアップのアジリティが高くなる。プロセスマネージャーが必要に応じてプロセスを新しい物理マシンに簡単に移動できるようになるため、堅牢性も高くなる。SIGTERMシグナルを受け取ったときに、グレースフルにシャットダウンする。Webプロセスの場合、グレースフルシャットダウンは、サービスポートのリッスンを中止し(従って新しいリクエストを拒み)、処理中のリクエストが終了するまで待ち、シャットダウンすることで実現される。このモデルでは暗黙的にHTTPリクエストが短い(せいぜい数秒)ことを仮定している。ロングポーリングの場合、クライアントはコネクションが失われたときに途切れなく再接続を試みるべきである。ワーカープロセスの場合、グレースフルシャットダウンは、処理中のジョブをワーカーキューに戻すことで実現される。RabbitMQではワーカーはNACKを送ることができる。Beanstalkdでは、ワーカーの接続が失われるとジョブは自動的にキューに戻る。Jobなどのロックをベースにしたシステムでは、ジョブレコードのロックを確実に解放する必要がある。このモデルでは、暗黙的にすべてのジョブが再入可能であることを仮定している。再入可能性は一般的に、結果をトランザクションで包んだり、処理をべき等にすることで実現される。このような事態が起こることは、SIGTERMによるグレースフルシャットダウンに比べればずっと少ないが、それでも起こりうる。この対策として推奨される方法は、Beanstalkdなどの堅牢なキューイングバックエンドを使い、クライアントの接続が切断されたり、タイムアウトしたときにジョブをキューに戻せるようにすることである。Appは予期しないグレースフルでない停止をうまく処理できるよう設計される。「クラッシュオンリー」設計はこのコンセプトをその論理的帰結に導く。