ヘルスチェック
Zeabur は、デプロイがトラフィックを受信する前に準備ができていることを確認するために、すべてのサービスで自動的にヘルスチェックを実行します。これにより、ゼロダウンタイムデプロイが実現されます。新しいデプロイがヘルスチェックに失敗した場合、以前のバージョンがリクエストの処理を継続します。
ヘルスチェックの仕組み
サービスをデプロイすると、Zeabur はサービスのリスニングポートをプローブして、接続を受け入れているかどうかを確認します。デプロイはヘルスチェックが成功した場合にのみ準備完了とみなされます。それまでは、以前のデプロイがアクティブなままトラフィックを処理し続けます。
つまり：
- ヘルスチェック成功 — トラフィックは新しいデプロイにルーティングされ、古いデプロイは終了します。
- ヘルスチェック失敗 — 新しいデプロイは失敗としてマークされ、古いデプロイがアクティブなままになります。ダウンタイムは発生しません。
ボリュームがアタッチされているサービスでは、Zeabur はローリングアップデートの代わりに Recreate デプロイ戦略を使用します。つまり、新しいデプロイが開始される前に古いデプロイが停止されるため、デプロイ中に短時間のダウンタイムが発生します。これは、2つのインスタンスが同時に同じボリュームにアクセスすることによるデータの競合を避けるために必要です。
デフォルトの動作
デフォルトでは、Zeabur はサービスの公開ポートが TCP 接続を受け入れているかどうかをチェックします。ほとんどの Web アプリケーションでは、これで十分です。HTTP サーバーがリスニングを開始すると、ヘルスチェックが成功します。
デフォルトの設定：
| パラメータ | デフォルト値 |
|---|---|
| チェックタイプ | TCP ポートプローブ |
| 間隔 | 10秒 |
| タイムアウト | 5秒 |
| 失敗しきい値 | 連続3回の失敗 |
カスタムヘルスチェックパス
より正確なヘルス検証のために、カスタム HTTP ヘルスチェックパスを設定できます。これは、アプリケーションがトラフィックを処理する準備が本当にできるまでに追加の起動時間が必要な場合（キャッシュのウォームアップやデータベース接続の確立など）に便利です。
カスタムヘルスチェックパスを設定するには：
- Zeabur ダッシュボードでサービスを開きます。
- Settings に移動します。
- Health Check セクションで、カスタムパス（例：
/healthzまたは/api/health）を入力します。
アプリケーションは、トラフィックを受信する準備ができたときに、そのパスで HTTP 2xx ステータスコードを返す必要があります。
// 例：Express.js ヘルスチェックエンドポイント
app.get('/healthz', (req, res) => {
// ここで準備チェックを実行
res.status(200).json({ status: 'ok' })
})トラブルシューティング
デプロイが「Deploying」状態のまま進まない
デプロイがヘルスチェックに通らない場合、以下を確認してください：
- アプリケーションが正しいポートでリスニングしているか。Zeabur は
PORT環境変数を設定します。アプリが0.0.0.0:$PORTにバインドしていることを確認してください。 - アプリケーションがタイムアウトウィンドウ内に起動しているか。初期化に時間がかかる場合は、すぐに応答する軽量なヘルスエンドポイントの追加を検討してください。
- カスタムヘルスチェックパスを使用している場合、エンドポイントが HTTP
2xxレスポンスを返していることを確認してください。
起動に時間がかかるサービス
一部のアプリケーション（Java サービスや大規模な ML モデルをロードするアプリケーションなど）は、初期化に追加の時間が必要な場合があります。このような場合は、デフォルトの TCP プローブに依存するのではなく、アプリケーションが完全に準備できた後にのみ成功レスポンスを返すカスタムヘルスチェックエンドポイントを設定してください。