> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pubrio.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Bonnes pratiques et polling
> Optimisez la configuration de vos moniteurs pour la fiabilité, la performance et une livraison efficace.
## Fréquence en temps réel
Le paramètre `frequency_minute` contrôle la fréquence de scan de votre moniteur.
| Réglage | Comportement | Cas d'usage |
| -------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------ |
| **`0` (par défaut)** | **Temps réel** — les signaux sont détectés et livrés dès leur apparition | La plupart des moniteurs — livraison la plus rapide possible |
| `1 - 60` | Intervalle fixe en minutes | Quand vous souhaitez une cadence prévisible |
| `60 - 1440` | De l'horaire au quotidien | Résumés type digest, signaux de priorité moindre |
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.
| Paramètre | Plage | Défaut | Recommandation |
| ----------------------- | ----- | ------ | ------------------------------------------------------------------------------------- |
| `max_retry_per_trigger` | 0 - 3 | 1 | Réglez sur 2-3 pour les moniteurs critiques |
| `retry_delay_second` | 1 - 5 | 1 | Utilisez 3-5 secondes pour laisser le temps aux problèmes transitoires de se résoudre |
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](/fr/api-reference/endpoint/monitors/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](/fr/api-reference/endpoint/monitors/statistics_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](/fr/api-reference/endpoint/monitors/statistics_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](/fr/api-reference/endpoint/monitors/update)
5. Utilisez [Process Retry](/fr/api-reference/endpoint/monitors/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](/fr/api-reference/endpoint/monitors/statistics) pour un contrôle de santé au niveau du dashboard :
```bash cURL theme={null}
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 }'
```
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](/fr/api-reference/endpoint/monitors/statistics_logs) pour consulter l'historique des déclenchements :
```bash cURL theme={null}
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
}'
```
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](/fr/api-reference/endpoint/monitors/monitors) 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](/fr/api-reference/endpoint/monitors/statistics) pour repérer rapidement les moniteurs sous-performants.