Glosario · Métricas de fiabilidad
Un presupuesto de errores es la cantidad de falta de fiabilidad que permite un objetivo de nivel de servicio (SLO) en un periodo: el 100 % menos el objetivo. Un SLO del 99,9 % en 30 días deja un presupuesto de errores de 43 minutos y 12 segundos de inactividad, o una petición fallida de cada mil.
El presupuesto convierte un SLO en una regla para tomar decisiones. Mientras quede presupuesto, el equipo publica cambios y asume riesgos planificados; cuando se agota, el trabajo de fiabilidad va primero hasta que la ventana se recupera. Acordar esa regla de antemano, en una política de error budget, es lo que hace útil la cifra.
Puede contarse en tiempo, como minutos de inactividad medidos con comprobaciones desde fuera, o en peticiones, como el porcentaje de peticiones fallidas en los logs del balanceador de carga o de la aplicación. Los presupuestos basados en tiempo encajan con cómo se redactan la mayoría de los SLA; los basados en peticiones dan más peso a las horas de mucho tráfico, lo que se acerca más a lo que perciben los usuarios.
Decide de antemano qué lo consume. Las caídas confirmadas, los errores, las respuestas más lentas que el límite del SLI y las caídas de proveedores de los que dependes suelen contar; los falsos positivos no deberían. La velocidad a la que se consume es el burn rate.
Error budget = (100 % − SLO) × ventana; presupuesto restante = error budget − caída hasta ahora
Ejemplo: Un SLO del 99,9 % en 30 días da 43 minutos y 12 segundos. Tras una caída de 25 minutos, se ha gastado el 58 % y quedan 18 minutos y 12 segundos.
Uptimecheck mide un margen basado en tiempo desde fuera de tu red: comprobaciones hasta cada minuto, cada fallo confirmado desde una segunda ubicación antes de que cuente y las ventanas de mantenimiento excluidas. Los informes muestran uptime, downtime e incidentes por monitor para este mes, el mes pasado o los últimos 7, 30 o 90 días frente a un objetivo de SLA del 99 % al 99,99 %, también en CSV. El margen restante es el downtime que permite el objetivo menos el downtime del informe; la app no lo muestra como un número aparte.
14 días de prueba gratis · Después, gratis con 5 monitores · Sin tarjeta de crédito
Guides 6 min de lectura
Cómo calcular un presupuesto de errores a partir de un SLO, qué lo consume, cómo funciona el burn rate y cómo redactar una política de presupuesto de errores que tu equipo cumpla de verdad.
LeerGuides 7 min de lectura
Un SLI mide cómo se comporta un servicio, un SLO es el objetivo para esa medición y un SLA es la promesa a los clientes. Definiciones, tablas de tiempo de inactividad y cómo fijar cada uno.
LeerGuides 6 min de lectura
Un 99,9 % de uptime permite 43 minutos y 49 segundos de inactividad en un mes medio. Qué permite cada nivel de nueves por día, mes y año, cómo miden los SLA el uptime, cómo funcionan los créditos de servicio y cómo elegir un objetivo.
LeerLo que diga tu política de error budget. Una regla habitual: hasta que la ventana se recupere solo se publican correcciones de errores y trabajo de fiabilidad, y los cambios arriesgados esperan.
Una ventana móvil de 30 días recuerda una mala semana durante un mes, lo que es más estricto. Un mes natural empieza de cero el día 1 y coincide con cómo se cuentan la mayoría de SLA y facturas. Elige uno y mantenlo.
Solo si el SLO lo dice. Muchos equipos excluyen el mantenimiento anunciado, con un límite al mes, para que no pueda ocultar caídas. En Uptimecheck, las ventanas de mantenimiento nunca cuentan como tiempo de inactividad.
Configura tu primer monitor en menos de un minuto, o echa antes un vistazo a la demo en vivo.
14 días de prueba gratis · Después, gratis con 5 monitores · Sin tarjeta de crédito
Con tu permiso, Google Analytics y Microsoft Clarity nos muestran qué páginas ayudan y dónde se atascan los visitantes. Instalan cookies durante un máximo de 13 meses. Sin tu permiso, ninguno de los dos se ejecuta. Puedes cambiar de opinión en cualquier momento en Configuración de cookies, al pie de la página. Política de privacidad