StripeのWebhookが届かないとき、最初の30分でやること
StripeのWebhookが届かない/遅延しているときに、最初の30分で「発火/到達/処理失敗」を切り分けて止血する手順です。
StripeのWebhookが届かない（または遅延している）とき、最初の30分でやるべきことは「本当にStripe→自分のサーバー間の問題か」「イベント自体が発火していないのか」「到達しているのに処理が失敗しているのか」を切り分けて、止血することです。
支払いが通っているのに権限が反映されない、メールが飛ばない、サブスク更新が反映されない、といった“売上に直結する事故”は、だいたいこの3つのどれかです。
0. まずやらないこと
- いきなりWebhook Secretをローテーションする（復旧が遅れやすい）
- いきなりイベント種類を闇雲に増やす（ノイズが増える）
- いきなりリリースや依存更新のせいにする（切り分けが遅れる）
最初の30分は「到達/処理/発火」の3分割で確定させます。
1. 事故の“症状”を1行で固定（3分）
まず、何が起きているのかを固定します。
- 支払いは成功しているのに: 反映（権限付与/メール/請求書送付）が遅い or されない
- 支払い自体が失敗している: これはCheckout/支払い側の問題なので、本記事の対象外
2. 「発火していない」か「届いていない」か「処理が失敗」かを分ける（10分）
Webhook問題は次の3つに分類できます。
- イベントが発火していない（想定したイベントがそもそも作られていない）
- イベントは発火しているが到達していない（Stripe→エンドポイントの配送に失敗）
- 到達しているが処理が失敗している（自分のサーバーが 4xx/5xx を返している・タイムアウト）
最初の30分で、この分類だけは確定します。
3. Stripe側で「配送失敗」かを確認（7分）
まずStripe側のイベント配送ログで、失敗や遅延が出ているかを確認します。
- 失敗のステータスが増えていないか
- 同じイベントが再試行され続けていないか
- 直近でWebhook URLや署名検証の実装を変えていないか
ここで配送失敗が見えるなら、原因は「到達できない/到達しても落ちる」に寄ります。
4. 自分側で「受け取っているのに落ちている」かを確認（7分）
Stripeが配送しているなら、自分側のログで次を確認します。
- Webhookリクエストが到達しているか（受信ログ/アクセスログ）
- 返しているHTTPステータスが 2xx か（4xx/5xx が出ていないか）
- タイムアウトが起きていないか（重い処理をWebhook内でやっていないか）
Webhook内で重い処理をしているなら、最初の止血は「受け取りだけ確実に成功させ、後段はキューに逃がす」です。
5. 「届いていない」が濃厚なときの最短チェック（6分）
到達しないときは、ほぼ以下のどれかです。
- エンドポイントのURLが間違っている/切り替わった
- 認証/リダイレクトなどで弾いている
- 503/タイムアウトなどでStripeが諦めている
最短の止血は「Webhookエンドポイントの可用性を戻す」「不要な弾き方をやめる」です。
6. 30分で出す“結論”の型
最初の30分で、次のどれかに分類して次の作業を固定します。
- 発火していない: 対象イベントが違う/期待している操作が違う。イベント種別の見直し。
- 到達していない: URL/可用性/弾き方が原因。まず到達できる状態に戻す。
- 到達しているが失敗: 4xx/5xx/タイムアウト。処理を軽くし、必ず2xxを返す。
この分類ができれば、次の1時間で“直す場所”を間違えません。
SiteOpsでWebhook事故の初動を速くする（再発防止）
Webhook事故は「どのイベントが」「いつから」「どの環境で」「どのサイトで」起きたかの確認が遅れるほど、返金・解約・サポートコストに直結します。
次からは、以下を“毎朝の確認”に組み込むと初動が速くなります。
- 直近24時間のStripe系異常（売上/決済/サブスク）を、優先順位付きで確認できる状態にする
- 変更（リリース/環境変数/ルーティング/認証/レート制限）と、異常の発生時刻を同じ画面で見られる状態にする
状況が複合している/原因の当たりが付かない場合は、止血を優先して相談だけ進めるのも有効です。
SiteOpsで初動を速くする（相談/導入）
- まずは ダッシュボード で、影響が出ているサイト（どの異常から触るべきか）を先に列挙します
- 相談したい場合は お問い合わせ から状況を送ってください（止血の順番を一緒に整理できます）
- 料金と導入の流れは 料金ページ にまとめています
関連
参考にした一次情報
この記事を書いた人
川原
SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。
関連記事
次にやること
複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。
料金を見る相談したい / お問い合わせ