メインコンテンツへスキップ

​
リアルタイムフリクエンシー

frequency_minute パラメータはモニターのスキャン頻度を制御します。
設定動作ユースケース
0（デフォルト）リアルタイム — シグナルが現れると同時に検出・配信ほとんどのモニター — 最速の配信
1 - 60固定間隔（分）予測可能なケイデンスが必要な場合
60 - 1440毎時〜毎日ダイジェスト形式のサマリー、低優先度のシグナル
frequency_minute: 0 に設定すると、Pubrioはシグナルが現れると同時に検出・配信します — ポーリング不要、遅延なし。

​
リトライ設定

ウェブフック配信が失敗した場合、リトライによる自動回復が可能です。
パラメータ範囲デフォルト推奨
max_retry_per_trigger0 - 31重要なモニターは2-3に設定
retry_delay_second1 - 51一時的な問題の解決を待つため3-5秒を使用
リトライは同じペイロードを再配信します — シグナル検出は再実行されず、追加の検索クレジットも発生しません。

​
プロセスリトライ

プロセスリトライ エンドポイントを使用すると、特定の失敗した配信を再試行できます。主なメリット：
  • 失敗時は課金なし — 配信が失敗した場合、クレジットは消費されません。クレジットは成功した配信時のみ課金されます。
  • トラブルシューティング — 失敗したログエントリを再試行して、新しいトリガーを作成せずにWebhookの問題を診断できます。
  • 元の配信先オプション — is_use_original_destination を使用すると、元のログの配信先スナップショットで再試行できます。障害後にWebhook URLを更新した場合に便利です。
統計ログ で失敗した配信を確認し、個別に再試行してください。

​
障害処理

max_failure_trigger パラメータ（範囲：1-10、デフォルト：5）は、モニターが自動的に一時停止するまでの連続配信失敗回数を制御します。 推奨アプローチ：
  1. 障害発生時にアラートを受信するため notification_email を設定
  2. プロダクションモニターは max_failure_trigger を3-5に維持
  3. 統計ログを使用して障害を診断 — error_message と response_status_code を確認
  4. 問題を修正後、モニター更新で再アクティベート
  5. プロセスリトライを使用して特定の失敗した配信を再試行

​
統計エンドポイントによるポーリング

ウェブフックがリアルタイム配信を処理する一方、統計エンドポイントはモニタリング、デバッグ、監査の機能を提供します。

​
オーバービューポーリング

モニター統計を使用してダッシュボードレベルのヘルスチェックを行います： 
curl -X POST https://api.pubrio.com/monitors/statistics \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{ "profile_id": 1 }'
集計メトリクスを返します：モニター総数、今日と昨日のトリガー数、成功率、比較率。

​
ログベースのポーリング

統計ログを使用してトリガー履歴を確認します： 
curl -X POST https://api.pubrio.com/monitors/statistics/logs \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{
    "profile_id": 1,
    "monitor_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "page": 1,
    "per_page": 10
  }'
各ログエントリにはステータス、クレジット使用量、シグナル/企業/人物の数、処理時間、エラー詳細が含まれます。
最大の信頼性を得るために、ウェブフック配信と定期的なログポーリングを組み合わせてください：ウェブフックがリアルタイム処理を担当し、ログポーリングが見逃した配信をキャッチして監査証跡を提供します。

​
スケーリングの推奨事項

過度に広範なモニターよりもフォーカスしたモニターを優先してください。「米国エンタープライズ企業のAI求人」を追跡するモニターは、「あらゆる場所のすべての求人」よりもデバッグが容易です。フォーカスしたモニターでは、異なるシグナルタイプを異なるウェブフックエンドポイントにルーティングすることも可能です。
ウェブフックエンドポイントは以下を満たすべきです：
  • 30秒以内にレスポンス
  • 即座に 200 を返し、データは非同期で処理
  • 重複ペイロードを適切に処理（冪等性）
  • デバッグのためにすべての受信ペイロードをログに記録
モニターリスト取得をフィルタリングと共に使用：
  • detection_mode と destination_type でフィルタリング
  • last_modified または last_trigger_at でソート
  • search_term で名前検索
モニター統計を使用してパフォーマンスの低いモニターをすばやく特定。