Saltar al contenido
Telemetry
Ganchos web receta SQL

Medir la recuperación del reintento del webhook

Separe las fallas permanentes del webhook de las entregas que se recuperaron en un intento posterior.

Intermediowebhook_deliveriesRevisado 2026-07-27Probado con Apache DataFusion 45.2.0

Revisado por el equipo de producto Telemetry en . Compatibilidad con SQL, contrato de eventos, resultados sintéticos y advertencias operativas. Revisar los estándares y la propiedad

Pregunta respondida

¿Los reintentos de webhook están recuperando fallas o creando más trabajo?

Un recuento bruto de fallos exagera el impacto en el cliente cuando los proveedores vuelven a intentarlo con éxito. Esta consulta muestra fallas iniciales, entregas recuperadas, fallas permanentes y supresión de duplicados juntos.

Contrato de evento

Campos que espera la consulta

CampoTipoPor que existe
timestamp_utcTimestampCuando finalizó el intento de procesamiento.
delivery_idUtf8Identificador estable compartido por reintentos.
providerUtf8Proveedor de webhook.
event_typeUtf8Tipo de evento del proveedor.
attemptInt64Intento de procesamiento basado en uno.
statusUtf8exitoso, fallido o deduplicado.
DataFusionSQL

Copiar la consulta

sql
WITH delivery_outcomes AS (
  SELECT
    delivery_id,
    provider,
    event_type,
    MAX(attempt) AS attempts,
    SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END) AS failed_attempts,
    SUM(CASE WHEN status = 'success' THEN 1 ELSE 0 END) AS successful_attempts,
    SUM(CASE WHEN status = 'deduplicated' THEN 1 ELSE 0 END) AS deduplicated_attempts
  FROM webhook_deliveries
  WHERE timestamp_utc >= now() - INTERVAL '7 days'
  GROUP BY delivery_id, provider, event_type
)
SELECT
  provider,
  event_type,
  COUNT(*) AS deliveries,
  SUM(CASE
    WHEN failed_attempts > 0 AND successful_attempts > 0 THEN 1 ELSE 0
  END) AS recovered,
  SUM(CASE
    WHEN failed_attempts > 0 AND successful_attempts = 0 THEN 1 ELSE 0
  END) AS permanent_failures,
  SUM(deduplicated_attempts) AS duplicates_suppressed
FROM delivery_outcomes
GROUP BY provider, event_type
ORDER BY permanent_failures DESC, recovered DESC;

Esta consulta de solo lectura se planifica y ejecuta en una tabla escrita vacía con Apache DataFusion 45.2.0. El resultado de la muestra determinista es sintético y se revisa por separado; valide tipos de campos, umbrales y definiciones comerciales con sus propios datos. Lea la metodología de prueba.

Resultado de la consulta

Fallos permanentes por evento de webhook

Los eventos recuperados permanecen visibles sin contarse como impacto permanente en el cliente.

providerevent_typedeliveriesrecoveredpermanent_failuresduplicates_suppressed
stripeinvoice.payment_succeeded4111
githubpush3101

Salida de ejemplo sintético. Ejecute la consulta con su propio esquema de eventos y umbrales antes de utilizarla para decisiones operativas.

Permanent failures by webhook event: gráfico estático de valores sintéticos de permanent_failures del resultado del ejemplo Measure Webhook Retry Recovery
SVG indexable de la salida del ejemplo determinista. Descárguelo para ver un artículo, un runbook o una revisión de diseño con atribución.

Reproducir el ejemplo

Descargar el accesorio público

El paquete JSON incluye el contrato de evento escrito, reproducible filas de entrada, SQL exacto, resultado esperado, notas de revisión y versión del motor. El CSV contiene el resultado mostrado.

Cómo funciona el SQL

  1. 1El primer CTE agrupa todos los intentos de una entrega en un único registro de resultados.
  2. 2Una entrega recuperada tiene al menos un intento fallido y al menos un intento exitoso. Un fracaso permanente nunca registró éxito.
  3. 3La supresión de duplicados se rastrea por separado porque la idempotencia correcta es un resultado saludable, no una falla de procesamiento.

Casos extremos para decidir

  • Conserve los ID de entrega del proveedor para que los reintentos se puedan agrupar de manera confiable.
  • Una entrega puede recuperarse después de la ventana de consulta; utilice una ventana lo suficientemente larga para cubrir el programa de reintentos del proveedor.
  • Separe el recibo de los efectos secundarios posteriores cuando el éxito requiere algo más que reconocer al proveedor.

Panel recomendado

  • Barras agrupadas: recuperadas y permanent_failures por event_type
  • Estadística: tasa de supresión de duplicados
  • Tabla: últimas fallas permanentes con contexto laboral aguas abajo

Guía de alerta

Alertar inmediatamente sobre fallos permanentes en caso de eventos críticos para los ingresos y sobre un aumento repentino de las entregas recuperadas como señal de alerta temprana.

Leer configuración de alerta

Pon la receta a trabajar

Instrumentación y guías relacionadas.

Definir los datos de origen

Esquemas de eventos para este análisis.

Continuar el análisis

Ejecútelo en eventos reales.

Crea una tabla, adapta los campos y guarda el resultado.

Comience gratis, envíe eventos estructurados y utilice el resultado de la consulta como un gráfico, un widget de panel compartido o una entrada de alerta.

Obtén una clave API