Si medís toda tu API con un solo porcentaje, te podés perder una caída de pagos mientras el tablero sigue “normal”. En eCommerce, no pesa igual un error en catálogo que un fallo en checkout: uno puede molestar; el otro te corta ventas en minutos.
Yo resumiría la idea así:
Hay dos datos que dejan esto claro: el 33% de los clientes no reintenta un pago fallido y el 17% de los abandonos en checkout se asocia a problemas técnicos. O sea: una alerta mal armada no solo falla en monitoreo; también puede pegar en ingresos y soporte.
Si yo tuviera que bajar todo el artículo a una guía corta, sería esta:
| Flujo | Qué medir | Qué excluir | Alerta base |
|---|---|---|---|
| Pagos / checkout | 5xx, timeouts y fallas del gateway | Rechazos normales del banco o antifraude | > 1,5% en 5 min y control en 1 hora |
| Catálogo | lecturas y sync de precios/stock con dato válido | errores de uso o de negocio esperados | > 7% en 30 min |
| Envíos | cotizaciones, etiquetas y tracking al día | direcciones inválidas | > 10% en 1 hora con mínimo de volumen |
| Devoluciones | alta de RMA y reembolsos dentro de plazo | devoluciones no elegibles | > 10% en 1 hora con mínimo de volumen |
En pocas palabras: yo no armaría alertas por plataforma, sino por flujo de negocio, con umbrales, ventanas, exclusiones, responsables y runbooks propios. Ese es el cambio que baja ruido, evita alertas al pedo y ayuda a ver antes los incidentes que de verdad te cuestan plata.
Copiar umbrales genéricos - por ejemplo, 5% para todos los endpoints - pasa por alto algo básico: no todos los flujos tienen el mismo volumen, el mismo impacto ni el mismo presupuesto de error. ¿Qué termina pasando? Mucho ruido donde casi no importa y, peor, silencio cuando se rompe algo crítico. Por eso, el foco no tiene que estar en promedios globales, sino en alertas por flujo.
La fatiga de alertas aparece cuando el equipo recibe cientos o miles de alertas por semana y apenas entre 2% y 5% pide intervención real.
El primer error es mezclar errores 4xx y 5xx en una sola métrica. Los 4xx no representan fallas de confiabilidad; los 5xx sí. Cuando se suman sin más, el uso normal de la API por parte de los usuarios infla la tasa de error y dispara alertas que no llevan a ninguna acción.
El segundo error, muy común en pagos, es tratar los rechazos esperados como si fueran fallas de confiabilidad. Un rechazo por fondos insuficientes o por reglas antifraude no es una falla técnica.
El tercer error es dejar de lado los endpoints de bajo tráfico y confiar solo en reportes mensuales de SLA. Una API de devoluciones que procesa pocas solicitudes por hora puede pasar dos horas con 100% de fallas sin que el porcentaje global de error supere un umbral fijo. Después, el reporte mensual muestra todo en verde, pero el equipo de soporte ya está tapado de tickets.
Por último, no separar fallas internas de incidentes en dependencias externas - gateways de pago, carriers, feeds de catálogo - hace que el equipo de plataforma pierda tiempo buscando bugs propios cuando el problema, en verdad, está en un proveedor de envíos.
El impacto cambia según el flujo, pero el patrón se repite: el problema se detecta tarde y casi siempre por síntomas indirectos.
| Dominio | Cómo falla el monitoreo | Consecuencia visible |
|---|---|---|
| Catálogo | Errores de sincronización diluidos en el volumen total | Productos sin stock real, precios desactualizados, lanzamientos que no aparecen en la tienda |
| Pagos | Fallas técnicas mezcladas con rechazos normales | Checkouts que fallan silenciosamente durante campañas; caída de conversión sin alerta |
| Envíos | Endpoints de bajo tráfico sin umbrales propios | Tarifas de envío incorrectas, seguimientos sin actualizar, demoras en generación de etiquetas |
| Devoluciones | Sin SLIs específicos ni ventanas cortas | Clientes que no pueden iniciar devoluciones, reembolsos demorados, pico de tickets de soporte |
Con estos patrones sobre la mesa, ya queda claro por qué el paso siguiente es definir SLIs por flujo y llevarlos a SLOs, SLAs y presupuesto de error.
Con el problema ya sobre la mesa, el paso que sigue es medir cada flujo con su propio SLI.
Primero conviene dejar claras cuatro piezas: SLI, SLO, SLA y presupuesto de error. Un SLI es la métrica que medís. Por ejemplo, el porcentaje de solicitudes de autorización de pago que devuelven HTTP 2xx en los últimos 60 minutos. Un SLO es el objetivo interno que fijás sobre ese SLI; por ejemplo, que el 99,7% de las autorizaciones salgan bien durante cada mes calendario. Un SLA es el compromiso contractual con comercios o socios, con penalidades si no se cumple. Y el presupuesto de error es la parte de fallas que ese SLO deja pasar: si el objetivo es 99,7%, el presupuesto mensual es 0,3% del total de solicitudes. Sin esa base, la alerta queda suelta y no refleja el impacto de negocio.
La diferencia más importante entre SLO y SLA es simple: el primero es interno y el segundo es contractual. En la práctica, los SLOs internos suelen ser más estrictos que los SLAs para dejar un margen. Si el SLO interno para lecturas de catálogo es 99,9% y el SLA promete 99,5%, podés bancarte incidentes menores sin caer en incumplimiento.
Desde ahí, el SLI tiene que definirse según el flujo, no según la plataforma.
No todos los flujos piden la misma forma de medir. Para lecturas de producto, sirve mirar la proporción de respuestas GET /products/{id} con HTTP 2xx y cuerpo válido en ventanas de 15 minutos; eso dispara alertas de catálogo. Para actualizaciones de stock, medí el porcentaje de PUT /inventory_updates con confirmación registrada en inventario en menos de 30 segundos, en ventanas de 5 minutos; cualquier caída activa revisión de sincronización. Para autorización de pagos, hace falta separar dos capas: el SLI técnico mide la tasa de éxito de POST /payments/authorize frente a errores técnicos como HTTP 5xx o timeouts y dispara incidentes de confiabilidad; el SLI de negocio sigue rechazos anómalos por marca de tarjeta o adquirente en Argentina y activa revisión operativa.
Con seguimiento de envíos, no alcanza con que el endpoint responda. El SLI que sirve de verdad mide si el estado se actualizó en las últimas 24 horas. Si no pasó, corresponde una alerta por datos desactualizados. Para devoluciones y reembolsos, los SLIs tienen que incluir el tiempo hasta obtener un ID de devolución válido y el porcentaje de reembolsos que llegan al estado completado dentro de 48 horas. Las dos métricas se conectan de forma directa con umbrales de escalado al equipo de soporte.
Una práctica muy útil es definir dos capas de SLI por flujo:
Con los SLIs ya definidos, toca fijar el objetivo y calcular el presupuesto. Tomá este caso: si en septiembre de 2026 el flujo de autorización de pagos recibe 1.000.000 de solicitudes y el SLO es 99,7%, el presupuesto de error mensual es 0,3%. O sea: hasta 3.000 fallas permitidas. Si el ticket promedio es de $ 15.000 y la mitad de esas fallas representa ventas perdidas, el impacto potencial supera los $ 22.500.000. Ahí el riesgo de negocio deja de ser abstracto.
La alerta no tendría que mirar solo la tasa de error. También tiene que mirar la velocidad con la que se consume el presupuesto. Si 1.500 de esas 3.000 fallas pasan en los primeros 3 días del mes, el presupuesto se quema antes de llegar a la mitad del período. Eso justifica una alerta de severidad alta con escalado inmediato. Si esas mismas 1.500 fallas se reparten a lo largo de 30 días, sigue siendo un tema a revisar, pero no prende fuego todo.
El SLA que salga de ese SLO puede incluir disponibilidad de al menos 99,7% durante cada mes calendario, excluyendo ventanas de mantenimiento programado comunicadas con al menos 48 horas de anticipación. También puede fijar que, si la tasa de error técnica supera 1% durante 15 minutos, se abra un incidente de severidad alta, se informe al cliente dentro de los 15 minutos y se trabaje con guardia 24x7.
Con el SLO y el presupuesto de error ya definidos, el paso siguiente es llevar eso a alertas por flujo. En la práctica, significa bajar esos límites a umbrales y ventanas según el tipo de operación.
Acá aparece un error muy común: aplicar el mismo umbral a todo. Y no funciona.
Un 5% de error en lecturas de catálogo durante 30 minutos puede ser molesto, pero manejable. Ese mismo 5% en POST /checkout durante 5 minutos puede pegar directo en las ventas.
El esquema de ventanas múltiples sirve justo para eso: separar picos agudos de degradaciones sostenidas. Para pagos y checkout, combiná una ventana corta de 5 minutos con una ventana larga de 1 hora. Para catálogo, conviene un umbral más amplio y, si querés cubrir caídas más lentas, sumar una alerta de advertencia aparte. En envíos y devoluciones, agregá un volumen mínimo dentro de la ventana para evitar ruido en endpoints con poco tráfico.
Tomá estos valores como punto de partida y ajustalos según el SLO de cada flujo.
| Flujo | Umbral crítico | Ventana corta | Ventana larga | Volumen mínimo en la ventana |
|---|---|---|---|---|
| Pagos / checkout | > 1,5% error | 5 min | 1 hora | 200 |
| Lecturas de catálogo | > 7% error | 30 min | - | 1.000 |
| Envíos | > 10% error | 1 hora | - | 30 fallas |
| Devoluciones | > 10% error | 1 hora | - | 30 fallas |
En endpoints de bajo volumen, como POST /returns o POST /shipments, ese mínimo en la ventana pesa mucho. Sin ese filtro, una falla aislada puede disparar una alerta al divino botón. También conviene vincular cada umbral con la velocidad de consumo del presupuesto de error. Si el flujo de pagos quema la mitad del presupuesto mensual en los primeros tres días, eso ya amerita una alerta de severidad alta, aunque el porcentaje puntual no parezca tan grave.
No hace falta armar un sistema eterno de niveles. Tres alcanzan, si están bien definidos.
Crítico implica impacto directo e inmediato en ingresos: usuarios que no pueden cerrar el checkout, pagos rechazados o pedidos que no se registran. La acción esperada es una alerta paginada al responsable de guardia en menos de 5 minutos. Si a las 18:05 se detecta el incidente y a las 18:20 sigue sin resolverse, escalá al responsable técnico. Si a las 18:35 el problema sigue abierto, avisá a los responsables de negocio con un resumen del impacto estimado en ARS.
Advertencia cubre degradaciones que dañan la experiencia, pero no frenan el flujo principal: respuestas lentas en catálogo, fallas parciales en devoluciones o demoras en la sincronización. En este caso, el equipo recibe una notificación por Slack o mail, con 30 minutos para confirmar recepción y abrir un ticket.
Informacional agrupa anomalías menores y tendencias que no exigen acción inmediata, pero sí sirven para el análisis semanal de incidentes.
La severidad solo sirve si cada nivel dispara una acción concreta. Si no, queda linda en el dashboard y poco más.
Una alerta útil le da a la persona de guardia el contexto mínimo para hacer triage sin salir corriendo a buscar logs a mano. Como base, cada alerta debería incluir:
El runbook, además, tiene que ser puntual para cada flujo. No alcanza con un “revisar logs” y listo.
Esta separación también corre cuando un mismo stack mueve comercio y mensajería. Los equipos que usan Burbuxa tienen que separar las alertas de sincronización de comercio de las de mensajería, porque cambia tanto el impacto como el responsable del incidente.
SLAs por Flujo de eCommerce: Umbrales, Ventanas y Escalado
Cada SLA tiene que dejar algo bien claro: qué cubre, cómo se mide, qué queda afuera, en qué ventana se mira, cuándo pasa a ser crítico, quién responde y cómo escala.
Con ese marco definido, el siguiente paso es llevarlo a un SLA operativo por flujo. Ahí es donde deja de ser teoría y pasa a servir en el día a día.
| Dominio | Alcance | SLI | Errores excluidos | Ventana | Umbral crítico | Responsable | Ruta de escalado |
|---|---|---|---|---|---|---|---|
| Pagos | Autorización, captura, reembolsos y flujos de fraude/3DS con gateways y medios de pago locales | ≥ 99,9% de llamadas exitosas al API de pagos en checkout | Rechazos esperados del banco emisor, tarjeta vencida, fraude bloqueado | 15 min | Caída superior a 3% o indisponibilidad total por más de 5 min | Lead de integraciones / SRE | SRE o técnico de guardia → CTO / gerente de eCommerce |
| Catálogo | Creación y actualización de productos, precios en ARS, stock, descuentos y estado de publicación en todos los canales | ≥ 99,5% de sincronizaciones de catálogo completadas en 60 min | Errores de negocio esperados, no fallas técnicas | 60 min | Falla generalizada de sincronización o caída total por más de 60 min | Gerente de eCommerce / merchandising | Integraciones / ingeniería → gerente de eCommerce / merchandising |
| Envíos | Cálculo de tarifas, generación de etiquetas, pedidos de retiro y eventos de tracking por transportista | ≥ 99,0% de cotizaciones y etiquetas generadas con éxito | Direcciones inválidas | 30 min | Falla de tarifas o etiquetas para la mayoría de las órdenes por más de 30 min | Líder de operaciones / logística | Logística → equipo técnico → soporte del transportista |
| Devoluciones | Creación de RMA, cambios de estado, emisión de reembolso o crédito | ≥ 99,0% de solicitudes de devolución creadas y actualizadas con éxito | Devoluciones fuera de plazo o no elegibles por política | 24 h | Imposibilidad de registrar devoluciones o emitir reintegros por más de 24 h | Líder de atención al cliente / operaciones | Atención al cliente / operaciones → equipo técnico |
Con esta matriz, cada flujo queda medido, asignado y escalado sin mezclar impactos. Eso evita un problema muy común: tratar igual una caída técnica y un rechazo esperado del negocio, cuando en la práctica no tienen el mismo peso ni piden la misma respuesta.
El punto central es que cada fila convierta un impacto técnico en una decisión operativa concreta. Dicho simple: si algo falla, el equipo tiene que saber qué pasó, a quién le pega y qué hacer después.
Separá las fallas técnicas de los rechazos esperados, vinculalo a un runbook y usá una ventana corta junto con una larga. Así podés detectar incidentes en el momento sin perder de vista el patrón general.
Elegí un resultado medible y llevalo a una métrica concreta del flujo, como la latencia p99 o la tasa de errores 4xx/5xx.
Después, definí umbrales y ventanas de evaluación según el impacto de cada paso. Por ejemplo, /checkout y /payments/process suelen pedir límites más duros, porque cualquier desvío ahí pega directo en la conversión.
También conviene mirar el flujo completo - carrito → descuento → pago - y no solo cada endpoint por separado. Eso te ayuda a separar una falla puntual de un endpoint de un problema más amplio en la integración general.
Conviene dejar afuera los eventos que no muestran una falla real del sistema o del proceso comercial.
Por ejemplo, entran en esa bolsa las solicitudes mal formadas (4xx) cuando vienen de acciones esperadas del usuario. También los intentos de intrusión o ataques que detecta el equipo de seguridad.
Si usás Burbuxa, suma separar los errores causados por límites de tasa o por caídas de plataformas externas. La razón es simple: no dependen de tu control operativo directo.
Basate en el contexto y en los patrones históricos: 300 ms puede estar bien en horas de baja actividad, pero volverse grave en picos de tráfico.
Recalibrá cuando cambie la estacionalidad o aparezcan eventos como Cyber Monday. En esos casos, conviene usar umbrales dinámicos y dar prioridad a las alertas en endpoints críticos como /checkout o /payments/process.
Si el MTTD pasa los 15 minutos, ajustá la configuración.
