> ## 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.
# Buenas prácticas y polling
> Optimiza la configuración de tu monitor para lograr fiabilidad, rendimiento y una entrega eficiente.
## Frecuencia en tiempo real
El parámetro `frequency_minute` controla la frecuencia con la que escanea tu monitor.
| Configuración | Comportamiento | Caso de uso |
| --------------------- | -------------------------------------------------------------------------- | ----------------------------------------------------------- |
| **`0` (por defecto)** | **Tiempo real** — las señales se detectan y entregan a medida que aparecen | La mayoría de los monitores — entrega lo más rápida posible |
| `1 - 60` | Intervalo fijo en minutos | Cuando quieres una cadencia predecible |
| `60 - 1440` | De cada hora a diario | Resúmenes tipo digest, señales de menor prioridad |
Con `frequency_minute: 0`, Pubrio detecta y entrega las señales a medida que aparecen — sin polling, sin retraso.
***
## Configuración de reintentos
Cuando falla la entrega de un webhook, los reintentos ayudan a recuperarse automáticamente.
| Parámetro | Rango | Por defecto | Recomendación |
| ----------------------- | ----- | ----------- | ------------------------------------------------------------------------------ |
| `max_retry_per_trigger` | 0 - 3 | 1 | Configúralo en 2-3 para monitores críticos |
| `retry_delay_second` | 1 - 5 | 1 | Usa entre 3 y 5 segundos para permitir que se resuelvan problemas transitorios |
Los reintentos vuelven a entregar el mismo payload — no vuelven a ejecutar la detección de señales ni consumen créditos de búsqueda adicionales.
***
## Process Retry
El endpoint [Process Retry](/es/api-reference/endpoint/monitors/process_retry) te permite reintentar una entrega fallida específica. Ventajas clave:
* **Sin cargo por fallos** — no se te cobran créditos cuando falla una entrega. Los créditos solo se consumen en una entrega exitosa.
* **Solución de problemas** — reintenta una entrada de log fallida para diagnosticar problemas del webhook sin crear nuevos triggers.
* **Opción de destino original** — usa `is_use_original_destination` para reintentar con la instantánea de destino del log original, útil cuando has actualizado la URL de tu webhook desde el fallo.
Encuentra las entregas fallidas mediante [Statistic Logs](/es/api-reference/endpoint/monitors/statistics_logs) y reinténtalas de forma individual.
***
## Gestión de fallos
El parámetro `max_failure_trigger` (rango: 1-10, por defecto: 5) controla cuántos fallos de entrega consecutivos se permiten antes de que el monitor se pause automáticamente.
**Enfoque recomendado:**
1. Configura `notification_email` para recibir alertas cuando ocurran fallos
2. Mantén `max_failure_trigger` entre 3 y 5 para monitores en producción
3. Usa [Statistic Logs](/es/api-reference/endpoint/monitors/statistics_logs) para diagnosticar fallos — revisa `error_message` y `response_status_code`
4. Después de solucionar el problema, reactiva el monitor mediante [Update Monitor](/es/api-reference/endpoint/monitors/update)
5. Usa [Process Retry](/es/api-reference/endpoint/monitors/process_retry) para reintentar entregas fallidas específicas
***
## Polling con los endpoints de estadísticas
Mientras los webhooks se encargan de la entrega en tiempo real, los endpoints de estadísticas ofrecen capacidades de monitoreo, depuración y auditoría.
### Polling general
Usa [Monitor Statistics](/es/api-reference/endpoint/monitors/statistics) para una verificación de estado a nivel de 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 }'
```
Devuelve métricas agregadas: total de monitores, triggers de hoy frente a ayer, tasas de éxito y tasas de comparación.
### Polling basado en logs
Usa [Statistic Logs](/es/api-reference/endpoint/monitors/statistics_logs) para revisar el historial de triggers:
```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
}'
```
Cada entrada de log incluye estado, uso de créditos, conteos de señales/empresas/personas, tiempo de procesamiento y detalles de error.
Combina la entrega por webhook con el polling periódico de logs para lograr la máxima fiabilidad: los webhooks gestionan el procesamiento en tiempo real, mientras que el polling de logs detecta cualquier entrega perdida y ofrece un registro de auditoría.
***
## Recomendaciones de escalado
**Prefiere monitores enfocados en lugar de otros excesivamente amplios.** Un monitor que rastrea "empleos de IA en empresas grandes de EE. UU." es más fácil de depurar que "todos los empleos en todas partes". Los monitores enfocados también te permiten enrutar distintos tipos de señal a distintos endpoints de webhook.
Tu endpoint de webhook debería:
* Responder en menos de 30 segundos
* Devolver `200` de inmediato y procesar los datos de forma asíncrona
* Manejar payloads duplicados de forma correcta (idempotencia)
* Registrar todos los payloads entrantes para depuración
Usa [Get Monitor List](/es/api-reference/endpoint/monitors/monitors) con filtrado:
* Filtra por `detection_mode` y `destination_type`
* Ordena por `last_modified` o `last_trigger_at`
* Busca por nombre con `search_term`
Usa [Monitor Statistics](/es/api-reference/endpoint/monitors/statistics) para detectar rápidamente monitores con bajo rendimiento.