Glosario · Métricas de fiabilidad

¿Qué es la tasa de consumo?

El burn rate es la velocidad a la que un servicio gasta su error budget en relación con lo que permite su SLO. Con un burn rate de 1, el presupuesto dura exactamente toda la ventana; con 2, se agota a mitad.

Cómo funciona y por qué importa

El burn rate compara la tasa de error que ves ahora con la que permite el SLO. Con un SLO del 99,9 %, la tasa de error permitida es del 0,1 %, así que un 0,5 % de peticiones fallidas es un burn rate de 5, y a ese ritmo un error budget de 30 días dura 6 días.

El workbook SRE de Google basa las alertas en ella. Para un SLO del 99,9 % en 30 días, propone avisar cuando se consume el 2 % del presupuesto en una hora (una tasa de consumo de 14,4) o el 5 % en seis horas (una tasa de 6), y abrir un ticket cuando se consume el 10 % en tres días (una tasa de 1). Cada alerta comprueba también una ventana corta, para que se detenga poco después de que lo haga el problema.

Una caída total consume rápido, y una simple alerta de “sitio caído” la detecta igual de rápido: frente a un 99,9 %, cada minuto caído es una tasa de consumo de 1000. Las alertas por tasa de consumo demuestran su valor en los fallos parciales, como un 2 % de peticiones fallando durante horas, que nunca tumba el sitio pero agota el presupuesto del mes.

Fórmula

Burn rate = tasa de error observada ÷ (100 % − SLO); tiempo hasta agotar el presupuesto = ventana ÷ burn rate

Ejemplo: Frente a un SLO del 99,9 %, una caída total consume a una tasa de 1000, así que 20 minutos gastan el 46 % de un presupuesto de 30 días de 43 minutos y 12 segundos. Con un 0,5 % de comprobaciones fallidas, la tasa es de 5 y el presupuesto se agota en 6 días.

Cómo ayuda Uptimecheck

Uptimecheck no calcula un burn rate. Para la disponibilidad, sus alertas cubren el extremo rápido: con un intervalo de 1 minuto, una caída confirmada por una segunda comprobación te llega en uno o dos minutos. Las alertas de lentitud, enviadas tras tres comprobaciones lentas seguidas, detectan un servicio que está activo pero va demasiado lento, y los informes de los últimos 7, 30 o 90 días muestran cuánto margen se ha gastado ya.

Ver Monitorización de uptime

14 días de prueba gratis · Después, gratis con 5 monitores · Sin tarjeta de crédito

Más en las guías

Guides 6 min de lectura

Presupuesto de errores: qué es y cómo usarlo

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.

Leer

Guides 7 min de lectura

Cómo reducir las falsas alertas en la monitorización de uptime

Las falsas alertas enseñan a los equipos a ignorar la monitorización. Cómo reducir el ruido: confirma cada fallo con una segunda comprobación, fija timeouts razonables, valida la URL correcta y envía las alertas a quien puede actuar.

Leer

Preguntas

¿Cuál es un buen umbral para las alertas de burn rate?

Un punto de partida habitual para un SLO del 99,9 % en 30 días es avisar a la guardia con una tasa de consumo de 14,4 durante una hora o de 6 durante seis horas, y abrir un ticket con 1 durante tres días. Ajústalo tras unos meses de alertas reales.

¿Por qué una alerta de burn rate usa dos ventanas?

La ventana larga garantiza que se haya consumido suficiente presupuesto como para importar. La corta garantiza que se sigue consumiendo, para que la alerta se detenga poco después de solucionar el problema.

¿Es mala una tasa de consumo de 1?

No. Gasta el presupuesto justo al final de la ventana, que es lo que permite el SLO. Por encima de 1, el presupuesto se agota antes; por debajo de 1, sobra algo.

Las caídas son cosa del pasado.

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