ForHosting KIT · サイト取得・監視

Webhook配信リトライ予定

基準1000で指数方式の再試行を5回行うと、待ち時間は1000・2000・4000・8000・16000で、合計31000です。回数・基準の待ち時間・方式を選ぶと、累計付きの予定表が分かります。ブラウザで無料で使えます。

無料
ブラウザで動作
登録不要
データは端末の外に出ません

無料で実行 API仕様を見る

ご利用方法ウェブAPIメールTelegramアプリ近日

計算例

入力した場合

最大リトライ回数: 5
基本の遅延: 1,000
戦略: Exponential

結果

遅延: 1,000, 2,000, 4,000, 8,000, 16,000
合計待機時間: 31,000
試行回数: 5

固定・線形・指数バックオフ

再試行の予定を書き出すべき理由

イベント通知の配信に失敗すると、送信側のシステムは少し待ってから再試行します。通知を配信する側と受け取る側には、どこかでバックオフが行われるというあいまいな約束ではなく、再試行ごとの待ち時間をはっきり並べた一覧が必要です。予定が公開されていないと、運用担当者は最悪の配信遅延を見積もれず、負荷のシミュレーションでも本番が試行の間に入れる正確な間隔を再現できません。このツールは最大再試行回数、0より大きい基準の待ち時間、方式を受け取り、各試行の待ち時間、累計、短い計算式を返します。式はダッシュボードの横や運用手順書に残しておけます。

固定・線形・指数の選び方とよくある間違い

固定のバックオフは毎回同じ基準の待ち時間を使うため分かりやすく、短い休止だけが必要な受け手にもやさしい方式です。線形は基準に1から数えた試行番号を掛けるので、後の試行ほど比例して長く待ちますが、指数ほど急には伸びません。指数は毎回倍になり、1000から5回なら1000・2000・4000・8000・16000で、合計は31000です。よくある間違いは基準を0や負の値にすることで、待ち行列が休みなく回り続けてしまうため、すぐに受け付けないようにしています。待ち時間はすべて同じ単位、通常はミリ秒でそろえてください。

よくある質問

予定に乱数ジッターは含まれますか？

ワーカー間の散らばりが必要なら、上に独自ジッターを載せてください。

指数方式で5回再試行すると合計でどれだけ待ちますか？

基準が1000なら、待ち時間は1000・2000・4000・8000・16000で、5回目の試行までの累計は31000になります。単位は選んだものと同じで、通常はミリ秒です。

固定・線形・指数のバックオフはどう違いますか？

固定は毎回同じ基準の待ち時間です。線形は基準に1から数えた試行番号を掛けます。指数は毎回待ち時間が倍になり、基準に2の（試行番号−1）乗を掛けた値です。

基準の待ち時間にはどの単位を使えばよいですか？

すべての待ち時間で同じ単位なら何でもかまいませんが、通常はミリ秒です。基準は0より大きい必要があり、0や負の値では待ち行列が休みなく再試行してしまうため、受け付けません。

何回まで再試行を計画できますか？

1回から100回までです。各試行の前に待ち時間が1つずつ割り当てられ、予定表には試行番号、その待ち時間、そこまでの累計が並ぶので、最悪の配信時間がすぐに分かります。

開発者向け — APIアクセス

このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。

エンドポイント

POSThttps://api.kit.forhosting.com/dev/webhook-retry-schedule-build

Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。

お使いのスタックから呼び出す

curl -X POST https://api.kit.forhosting.com/dev/webhook-retry-schedule-build \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"max_retries":5,"base_delay":1000,"strategy":"exponential"}'

const res = await fetch("https://api.kit.forhosting.com/dev/webhook-retry-schedule-build", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "max_retries": 5,
    "base_delay": 1000,
    "strategy": "exponential"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/dev/webhook-retry-schedule-build",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "max_retries": 5,
    "base_delay": 1000,
    "strategy": "exponential"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/webhook-retry-schedule-build", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"max_retries":5,"base_delay":1000,"strategy":"exponential"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"max_retries":5,"base_delay":1000,"strategy":"exponential"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/webhook-retry-schedule-build", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

リクエスト例

{
  "max_retries": 5,
  "base_delay": 1000,
  "strategy": "exponential"
}

レスポンス例

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.webhook_retry_schedule_build",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。

料金

1リクエストあたり$0.002

単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。

エラー

HTTP	コード	意味
`401`	`unauthorized`	APIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。
`402`	`insufficient_balance`	残高が不足しています。チャージ後に再度お試しください。
`404`	`unknown_type`	指定されたタスクタイプは存在しません。タイプ名を確認してください。
`429`	`rate_limited`	リクエストが多すぎます。しばらく待ってから再度お試しください。

技術的な注記

Webhook受信側と配信ワーカーには、各再試行前の待ち時間の明示的な一覧が必要であり、スタックのどこかでバックオフが適用されるという曖昧な約束では足りません。このWebhook配信リトライ予定ビルダーは、最大再試行回数、厳密に正の基準遅延、および固定・線形・指数のいずれかの戦略を受け取り、試行ごとの遅延、累積待ち時間、テストに固定したりダッシュボード横に表示したりできる短い式文字列を返します。同じ純粋ロジックがブラウザでは無料で、API経由でも動くため、オフラインで五段の指数ラダーを計画した結果は、通知パスや独自配信ループを設定するエッジワーカーが使う内容と一致します。無効な基準遅延は、キューを忙しいループにするゼロや負の待ち時間を捏造する代わりに、invalid_inputで即座に失敗します。

Webhookリトライ予定とは何か、三つの戦略はどう違うか

公開された予定がなければ、運用担当は最悪ケースの配信遅延を見積もれず、負荷試験は本番ワーカーが再試行の間に入れる正確な間隔を再現できません。固定バックオフは毎回同じ基準遅延を保ち、理解しやすく、短い冷却だけで足りる下流にもやさしいです。線形バックオフは基準遅延に1始まりの試行番号を掛け、後の再試行ほど比例して長く待ちつつ、純粋な指数成長ほど急激には増えません。Webhook配信リトライ予定とは、購読者URLへの失敗したPOSTのあと、試行1、試行2と続く前に待つ遅延の順序付き一覧です。この機能は、メッセージバスやHTTPクライアントで使われる三つの一般的なバックオフ系統を実装します。指数バックオフは、base_delay に 2 の（試行番号−1）乗を掛けて前回の遅延を倍々にし、一時的なネットワーク障害やレート制限向けの定番パターンです。max_retries には具体化する再試行スロット数、base_delay には選んだ単位（多くはミリ秒）の正の種、strategy には fixed・linear・exponential のいずれかを渡します。応答はそれらの入力を返し、遅延を順に並べ、total_wait として合計し、試行番号・遅延・累積待ちを持つ schedule 配列を展開するので、UIチャートや設定ジェネレータに余分な計算は不要です。

入力契約、応答形、検証が失敗するとき

ゼロと負値は、非正の待ちが忙しいスピンになるか計画として無意味なため拒否されます。strategy は trim 後に大文字小文字を無視した fixed・linear・exponential の文字列でなければなりません。乱散が必要なら独自のジッター方針と組み合わせてください。必須三フィールドの JSON 本体を POST してください。max_retries は予定する再試行回数を示す 1 から 100 の整数です。base_delay は一貫した任意単位の、ゼロより厳密に大きい有限数です。retries・base_ms・backoff などの別名キーを受け入れるので、既存の設定形をきれいに写せます。欠落フィールド、整数でない max_retries、有限でない base_delay、未知の strategy はすべて invalid_input を起こし、課金されません。成功時の本体には max_retries、base_delay、strategy、平坦配列の delays、遅延合計の total_wait、max_retries と等しい attempt_count、attempt・delay・cumulative を持つ schedule オブジェクト、選んだ戦略の閉形式を述べる formula が含まれます。例: max_retries 五、base_delay 千、strategy exponential は遅延千・二千・四千・八千・一万六千と total_wait 三万一千を返します。このエンドポイントは結果をブラウザと API で決定的に保つため、ジッターと壁時計タイムスタンプを意図的に省きます。max_retries の上限は百で、誤入力が巨大ペイロードや大きな指数ラダーでの中間積のオーバーフローに広がらないようにしています。

実システムでリトライ予定の構築が価値を生む場面

負荷試験ハーネスは本番ワーカーと同じ遅延配列を注入し、ステージングが本番より速く再試行してレート制限バグを隠す古典的なずれを解消します。検証失敗は残高を消費しません。Webhook の信頼性設定を公開する配信プラットフォームは、運用担当が最大再試行とバックオフモードを選んだときにこのビルダーを呼び、結果の遅延をエンドポイント秘密と署名鍵の隣に保存できます。インシデント用ランブックは印刷可能な total_wait があると、オンコール担当が不安定な購読者が最後の試行までどれだけ遅れるかを把握できます。OpenAPI や SDK の生成器は、実行時コードからずれる手作業テーブルを持たずに具体的な例ラダーを文書化できます。実装は純粋な parse の tier A のため、成功した呼び出しはモデルトークンも外向きネットワークもなく公開の基本料金 $0.002 です。スケジュールをワーカーループに配線するとき、base_delay と total_wait を sleep プリミティブと同じ単位に保ち、ミリ秒を秒に誤変換しないようにしてください。

連携の活用例

ダッシュボードでWebhook配信バックオフを設定する

運用担当が最大再試行と固定・線形・指数の戦略を選び、計算した遅延一覧を各購読エンドポイントの隣に永続化できるようにします。

最悪ケースの配信遅延を文書化する

ランブックに total_wait と試行ごとの累積遅延を示し、オンコールがデッドレター前に再試行がどれだけかかるかを把握できるようにします。

CIでゴールデン予定を固定する

設定ファイルが本番ワーカーと同じ遅延配列に展開されることを断言し、strategy や base_delay の偶発的な回帰を検知します。

技術的な質問

Webhook配信リトライ予定はどう構築しますか？

max_retries（1–100）、正の base_delay、strategy の fixed・linear・exponential を送ってください。API は順序付き遅延、total_wait、各試行の累積待ちを含む予定を返します。

固定・線形・指数バックオフの違いは何ですか？

固定は毎回 base_delay を繰り返します。線形は base_delay に試行番号を掛けます。指数は base_delay に 2 の（試行番号−1）乗を掛けます。

なぜ base_delay は正でなければなりませんか？

ゼロや負の遅延は再試行前の意味ある待ちを定義できず、配信ワーカーの忙しいループを招く恐れがあります。非正の base_delay は invalid_input で失敗し、課金されません。

Webhookリトライ予定の構築の料金は？

ブラウザツールは無料です。API 要求は成功した呼び出しごとに前払い KIT 残高から $0.002 です。無効な入力は課金されません。

KITの完全なドキュメントを見る →