Skip to main content

​
Frecuencia en tiempo real

El parámetro frequency_minute controla la frecuencia con la que escanea tu monitor.
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.
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 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 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 para diagnosticar fallos — revisa error_message y response_status_code
  4. Después de solucionar el problema, reactiva el monitor mediante Update Monitor
  5. Usa 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 para una verificación de estado a nivel de dashboard:
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 para revisar el historial de triggers:
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 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 para detectar rápidamente monitores con bajo rendimiento.