Skip to main content

​
Fréquence en temps réel

Le paramètre frequency_minute contrôle la fréquence de scan de votre moniteur.
Avec frequency_minute: 0, Pubrio détecte et livre les signaux dès leur apparition — pas de polling, pas de délai.

​
Configuration des nouvelles tentatives

Lorsqu’une livraison de webhook échoue, les nouvelles tentatives permettent une récupération automatique.
Les nouvelles tentatives relivrent la même charge utile — elles ne relancent pas la détection de signal et n’engendrent pas de crédits de recherche supplémentaires.

​
Nouvelle tentative de traitement

Le point de terminaison Process Retry vous permet de retenter une livraison en échec spécifique. Avantages clés :
  • Aucuns frais en cas d’échec — vous n’êtes pas facturé en crédits lorsqu’une livraison échoue. Les crédits ne sont consommés qu’en cas de livraison réussie.
  • Dépannage — retentez une entrée de journal en échec pour diagnostiquer des problèmes de webhook sans créer de nouveaux déclencheurs.
  • Option de destination d’origine — utilisez is_use_original_destination pour retenter avec l’instantané de destination du journal d’origine, utile si vous avez mis à jour votre URL de webhook depuis l’échec.
Trouvez les livraisons en échec via Statistic Logs et retentez-les individuellement.

​
Gestion des échecs

Le paramètre max_failure_trigger (plage : 1-10, défaut : 5) contrôle le nombre d’échecs de livraison consécutifs autorisés avant que le moniteur ne se mette automatiquement en pause. Approche recommandée :
  1. Configurez notification_email pour recevoir des alertes en cas d’échec
  2. Maintenez max_failure_trigger entre 3 et 5 pour les moniteurs de production
  3. Utilisez Statistic Logs pour diagnostiquer les échecs — vérifiez error_message et response_status_code
  4. Après avoir corrigé le problème, réactivez via Update Monitor
  5. Utilisez Process Retry pour retenter des livraisons en échec spécifiques

​
Polling avec les points de terminaison de statistiques

Alors que les webhooks gèrent la livraison en temps réel, les points de terminaison de statistiques offrent des capacités de suivi, de débogage et d’audit.

​
Polling d’ensemble

Utilisez Monitor Statistics pour un contrôle de santé au niveau du dashboard :
Renvoie des métriques agrégées : total de moniteurs, déclenchements aujourd’hui contre hier, taux de succès et taux de comparaison.

​
Polling basé sur les journaux

Utilisez Statistic Logs pour consulter l’historique des déclenchements :
Chaque entrée de journal inclut le statut, la consommation de crédits, le nombre de signaux/entreprises/personnes, le temps de traitement et les détails d’erreur.
Combinez la livraison par webhook avec un polling périodique des journaux pour une fiabilité maximale : les webhooks gèrent le traitement en temps réel, tandis que le polling des journaux détecte les livraisons manquées et fournit une piste d’audit.

​
Recommandations pour la montée en charge

Préférez des moniteurs ciblés à des moniteurs trop larges. Un moniteur suivant « les offres d’emploi IA dans les grandes entreprises américaines » est plus facile à déboguer que « toutes les offres partout ». Les moniteurs ciblés vous permettent aussi d’acheminer différents types de signaux vers différents points de terminaison de webhook.
Votre point de terminaison webhook devrait :
  • Répondre en moins de 30 secondes
  • Renvoyer 200 immédiatement et traiter les données de manière asynchrone
  • Gérer les charges utiles dupliquées avec grâce (idempotence)
  • Journaliser toutes les charges utiles entrantes pour le débogage
Utilisez Get Monitor List avec des filtres :
  • Filtrez par detection_mode et destination_type
  • Triez par last_modified ou last_trigger_at
  • Recherchez par nom avec search_term
Utilisez Monitor Statistics pour repérer rapidement les moniteurs sous-performants.