# Qué es un SLO: Objetivos de nivel de servicio explicados URL: https://formula.dog/es/journal/que-es-un-slo Type: blog Locale: es Published: 2026-10-03 Updated: 2026-10-03 --- > ¿Qué es un SLO, cómo funciona un presupuesto de error, y cómo rastrearlo en Excel o Google Sheets? Fórmulas incluidas. Entonces, ¿qué es un SLO? Un objetivo de nivel de servicio es una meta de confiabilidad que estableces para un servicio, expresada como un número durante un período de tiempo. "99.9% de las solicitudes tienen éxito en 30 días" es un SLO. Le dice a tu equipo cuánto fallo es aceptable antes de dejar de implementar y empezar a reparar. La matemática detrás es una simple división, por eso una hoja de cálculo la maneja perfectamente. Biscuit ya encontró las fórmulas. Tú traes los números. ## Los tres acrónimos que siempre ves, clasificados SLI, SLO, SLA. La gente los mezcla en las reuniones, así que aquí está la versión corta. - **SLI (indicador de nivel de servicio)**: lo que mides. El porcentaje de solicitudes que se devuelven sin error, porcentaje de páginas que cargan en menos de 300 ms, porcentaje de trabajos que se completan a tiempo. - **SLO (objetivo de nivel de servicio)**: la meta para esa medida. "El SLI debe ser al menos 99.9% en 30 días." - **SLA (acuerdo de nivel de servicio)**: un contrato con consecuencias, generalmente dinero de vuelta, adjunto a una meta. La prueba más clara viene del libro de SRE de Google: pregunta qué sucede si pierdes la meta. Si nada contractual sucede, [estás viendo un SLO, no un SLA](https://sre.google/sre-book/service-level-objectives/). Tu SLO debe ser más estricto que cualquier SLA que hayas firmado, para que obtengas una advertencia antes de que un cliente obtenga un reembolso. En términos de hoja de cálculo: el SLI es una columna de medidas, el SLO es una celda con la meta, y el SLA es un PDF que alguien en legal guarda. ## Por qué 99.9% y 99.99% son promesas muy diferentes Cada nueve adicional reduce tu tiempo de inactividad permitido por un factor de diez. En un mes de 30 días (43,200 minutos), aquí está lo que cada meta te deja: - **99%**: presupuesto de 1%, 432 minutos (7.2 horas) de tiempo de inactividad permitido por 30 días - **99.5%**: presupuesto de 0.5%, 216 minutos (3.6 horas) - **99.9%**: presupuesto de 0.1%, 43.2 minutos - **99.95%**: presupuesto de 0.05%, 21.6 minutos - **99.99%**: presupuesto de 0.01%, 4.32 minutos Esa última línea es la trampa. Cuatro minutos al mes significa que un humano ni siquiera puede terminar de leer la alerta antes de que el presupuesto se agote. La mayoría de herramientas internas, paneles y productos pequeños de SaaS no la necesitan, y perseguirla cuesta dinero real en redundancia y horas de guardia. Evita 99.99% a menos que un cliente te pague específicamente por ello. El consejo de Google también es directo: [comienza con una meta flexible que puedas ajustar después](https://sre.google/sre-book/service-level-objectives/), porque una estricta que tengas que relajar le enseña a todos a ignorar el número. ![Close-up of a fuel gauge needle, a picture of an error budget being spent](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-10/3bd194-i1.webp) ## El presupuesto de error: el número sobre el que realmente discute tu equipo El presupuesto de error es lo que el SLO deja. Apunta a 99.9%, así que el presupuesto es 0.1%. En 30 días, eso son 43.2 minutos de tiempo "malo" que tienes permitido gastar. Piénsalo como una medida de combustible. Los despliegues arriesgados queman combustible. Una mala migración de base de datos quema combustible. Una interrupción a las 3 a.m. quema mucho combustible. Cuando el tanque está lleno, implementa más rápido. Cuando está vacío, deja de agregar funciones y arregla la confiabilidad. La política de ejemplo de Google es concreta al respecto: si un servicio agota su presupuesto en una ventana de cuatro semanas, [todos los cambios se detienen excepto las correcciones P0 y los parches de seguridad](https://sre.google/workbook/error-budget-policy/) hasta que el servicio vuelva dentro de su SLO. El presupuesto es una herramienta de negociación, no un castigo. Permite que un gerente de producto y un ingeniero discutan desde la misma celda en lugar de desde sensación. Vale la pena si tienes más de un equipo tocando el mismo servicio. Excesivo si eres un fundador solitario con una página de destino y un formulario de contacto. ## Elegir un SLI que tus usuarios reconozcan Los mejores SLI describen un momento que una persona notaría. Tres cubren la mayoría de servicios: - **Disponibilidad**: el porcentaje de solicitudes que tienen éxito. Fácil de medir, fácil de explicar. - **Latencia**: el porcentaje de solicitudes más rápidas que un umbral. "95% de búsquedas se devuelven en menos de 300 ms" es mejor que un promedio, porque los promedios ocultan la cola lenta que molesta a la gente. - **Frescura**: para canalizaciones de datos e informes, el porcentaje de ejecuciones que se completan antes de la fecha límite. Esta se ajusta bien a la gente de hojas de cálculo: "la hoja de ventas de la mañana se actualiza antes de las 8 a.m. en 99% de los días de semana." Escribe el SLI como una fracción: eventos buenos divididos por eventos válidos. Ese único hábito hace que cada SLO sea calculable en una única celda, y te obliga a decidir qué cuenta como "bueno" antes del incidente, no durante él. Para la ventana, una media móvil de 30 días es la opción habitual. Un mes de calendario es más simple de reportar pero reinicia el presupuesto el 1º, lo que tienta a los equipos a empujar despliegues arriesgados a fin de mes. En una hoja, una ventana móvil simplemente significa filtrar la pestaña de Incidentes a los últimos 30 días con `SUMIFS(Incidents!C:C,Incidents!A:A,">="&TODAY()-30)`. ## Construir un rastreador de SLO en Google Sheets o Excel en 10 minutos No necesitas una plataforma de monitoreo para comenzar. Necesitas dos pestañas: **Incidentes** y **SLO**. En la pestaña **Incidentes**, registra cada interrupción con una hora de inicio en la columna A, una hora de fin en la columna B, y la duración en la columna C: `=(B2-A2)*24*60` - `B2` y `A2`: la fecha y hora finales e iniciales del incidente. - `*24*60`: convierte la diferencia basada en días a minutos. Funciona en Excel y Sheets, todas las versiones. Ahora la pestaña **SLO**. Pon estas etiquetas en la columna A y las fórmulas en la columna B: `B1: 0.999 (tu meta de SLO) B2: 30 (ventana en días) B3: =B2*24*60 (total de minutos en la ventana) B4: =B3*(1-B1) (presupuesto de error en minutos) B5: =SUM(Incidents!C2:C) (tiempo de inactividad hasta ahora) B6: =1-B5/B3 (disponibilidad real) B7: =B4-B5 (presupuesto restante, en minutos) B8: =B5/B4 (porcentaje del presupuesto quemado)`Con una meta de 99.9%, `B3` devuelve 43200 y `B4` devuelve 43.2. Registra una interrupción de 12 minutos y `B8` muestra 27.8%. Aquí está lo que parece en una celda real. Una nota sobre `C2:C` en `B5`: el rango abierto es sintaxis de Sheets. En Excel, usa un rango fijo como `Incidents!C2:C500` o una referencia de tabla. Agrega una celda de estado para que nadie tenga que leer el número: `=IF(B8>=1,"Congelar despliegues",IF(B8>=0.5,"Cuidado","Implementa"))` - `B8>=1`: presupuesto completamente gastado o excedido. - `B8>=0.5`: la mitad se ha ido, así que revisa cambios arriesgados. - Cualquier otra cosa: luz verde. Elige tus propios umbrales. Cincuenta por ciento es un comienzo, no una ley de la física. ¿Atascado en la sintaxis para tu propia versión de esta hoja? Descríbelo en inglés simple y deja que la herramienta lo escriba. ### Contar solicitudes en lugar de minutos El rastreo basado en tiempo es fácil de explicar pero crudo. Si tu servicio está "caído" durante 5 minutos a las 4 a.m. cuando nadie está en línea, eso duele menos que 5 minutos al mediodía. La mayoría de los equipos serios definen el SLI por solicitudes en su lugar. Pega una exportación de tu registro de solicitudes en una pestaña, con el código de estado HTTP en la columna B. Entonces: `=1-COUNTIF(B2:B,">=500")/COUNTA(B2:B)` - `COUNTIF(B2:B,">=500")`: cuenta solicitudes que devolvieron un error del servidor. - `COUNTA(B2:B)`: cuenta todas las solicitudes. Uno menos la proporción de error te da la proporción de éxito. El resultado es tu SLI de disponibilidad como fracción. Compáralo con la celda de meta y tienes el SLO completo en una línea. Excel 2016 y 365 ambos aceptan `COUNTIF`; solo intercambia `B2:B` por un rango limitado. Dos advertencias honestas. Las hojas de cálculo se atascan con millones de filas, así que exporta totales diarios en lugar de registros sin procesar. Y una respuesta 4xx es generalmente el error del usuario, no tu interrupción, así que decide esa regla una vez y escríbela. ![Notebook, pencil, coffee and a stopwatch laid out for tracking uptime by hand](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-10/ebd9a7-i2.webp) ## Velocidad de quemado: la fórmula que te advierte antes de que sea demasiado tarde Saber que quemaste 27.8% de tu presupuesto es agradable. Saber que lo estás quemando más rápido que el calendario es útil. Esa relación es la velocidad de quemado. `=B8/(B9/B2)` - `B8`: porcentaje del presupuesto quemado hasta ahora. - `B9`: días transcurridos en la ventana (ingrésalo manualmente o usa `=TODAY()-B10`, con la fecha de inicio de la ventana en `B10`). - `B2`: ventana total en días. Una velocidad de quemado de 1 significa que terminarás la ventana con exactamente cero presupuesto restante. Por encima de 1, te diriges a una congelación. Por debajo de 1, tienes espacio. Si estás 10 días en una ventana de 30 días y ya quemaste 60%, la velocidad de quemado es 1.8. Ese es el número a poner en una pantalla. Esta es la misma idea que las herramientas de monitoreo grandes usan para alertas de velocidad de quemado. Una hoja no te buscará a las 3 a.m., aunque, así que trátala como una capa de información, no como una alarma. Aquí hay un ejemplo trabajado con números reales. Tu SLO es 99.9% en 30 días, así que el presupuesto es 43.2 minutos. Día 1 al 8: un despliegue malo baja la página de pago durante 14 minutos. Eso es 32.4% del presupuesto en una cuarta parte de la ventana, una velocidad de quemado de alrededor de 1.2. Nada está en llamas, pero la hoja ahora dice "Cuidado", y la siguiente migración arriesgada recibe una segunda mirada. Día 15: una interrupción del proveedor suma 30 minutos. Total 44 minutos, 101.9% quemado. La celda de estado se invierte a "Congelar despliegues", y la conversación sobre prioridades sucede con un número en la mesa en lugar de un sentimiento. Ese es el valor completo del ejercicio. No los nueves, sino la celda compartida en la que todos pueden apuntar. ## Cuándo la hoja de cálculo se queda corta Un rastreador como este funciona para uno o dos servicios y una revisión semanal. Se desmorona cuando tienes docenas de servicios, necesitas recopilación de datos automática, o quieres alertas que se activen en minutos en lugar de en la próxima reunión del lunes. Es hora de mirar una herramienta de observabilidad adecuada. Datadog y Grafana tienen características nativas de SLO que extraen el SLI directamente de tus métricas y dibujan el presupuesto para ti. Elige Grafana si quieres código abierto y ya ejecutas Prometheus. Elige Datadog si prefieres pagar para no ejecutar nada tú mismo. De cualquier manera, mantén la hoja de cálculo cerca para la presentación de revisión mensual, porque todos en la sala pueden abrirla y nadie necesita un inicio de sesión en un proveedor. Si quieres ayuda redactando un primer conjunto de SLI para un servicio, un asistente general es un buen compañero para lluvia de ideas. Verifica cada número que te da, ya que alegremente inventará una meta que suena plausible. ## Errores que hacen inútil un SLO, y qué hacer el lunes Algunos patrones que Biscuit ha visto acabar mal: - **Copiar tu desempeño actual como la meta.** Si ejecutaste al 99.97% el trimestre pasado, un SLO de 99.97% fija un ritmo que tal vez no puedas mantener. - **Demasiados SLO.** Dos o tres por servicio. Pasado eso, nadie recuerda cuál importa. - **Medir lo que es fácil, no lo que los usuarios sienten.** El uso de CPU no es un SLI. Los checkouts fallidos lo son. - **Sin consecuencia.** Un SLO sin una política de presupuesto de error es un deseo. Decide por adelantado qué sucede en 50%, 100% y 150% quemado. - **Nunca revisando la meta.** Revísala cada trimestre. Si nunca te acercas a gastar el presupuesto, la meta es demasiado flexible. ![Golden retriever asleep in a quiet home office at night while the dashboard stays green](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/formula-dog/2026-10/560fcb-i3.webp) Ahora la parte del lunes. Elige un servicio. Escribe un SLI en una sola frase que un no ingeniero pudiera seguir. Establece una meta flexible, 99.5% o 99.9%. Construye las dos pestañas anteriores, registra los incidentes del mes pasado, y ve qué dice el presupuesto. Si la respuesta es "quemamos 300% de ello", acabas de descubrir por qué todos se sienten cansados. Si la respuesta es "quemamos 4%", ajusta la meta o implementa más rápido. De cualquier manera, ahora tienes un número sobre el que discutir en lugar de un sentimiento. Buen chico. Ahora ve a registrar esos incidentes. ## FAQ ### ¿Qué es un SLO en términos simples? Un SLO (objetivo de nivel de servicio) es una meta de confiabilidad para un servicio, como '99.9% de las solicitudes tienen éxito en 30 días'. Convierte una meta vaga como 'ser confiable' en un número que tu equipo puede medir y rastrear. ### ¿Cuál es la diferencia entre un SLO y un SLA? Un SLO es una meta interna. Un SLA es un contrato con consecuencias, generalmente reembolsos o créditos, si se pierde la meta. Si perder el número no tiene consecuencias contractuales, es un SLO. Establece tu SLO más estricto que tu SLA. ### ¿Qué es un presupuesto de error? El presupuesto de error es la cantidad de fallo que tu SLO permite. Un SLO de 99.9% deja un presupuesto de 0.1%, que son 43.2 minutos de tiempo de inactividad en 30 días. Los equipos lo gastan en incidentes y despliegues arriesgados, y desaceleran cuando se agota. ### ¿Cómo calculas un SLO en Excel o Google Sheets? Calcula los minutos totales en la ventana (días*24*60), multiplica por (1 - meta) para obtener el presupuesto, luego resta el tiempo de inactividad registrado. Para SLI basados en solicitudes, divide solicitudes buenas por solicitudes totales, por ejemplo con COUNTIFS y COUNTA. ### ¿Cuál es una buena meta de SLO? Comienza flexible, luego ajusta. 99.5% o 99.9% se ajusta a la mayoría de herramientas internas y pequeños productos. 99.99% deja alrededor de 4 minutos de tiempo de inactividad al mes y rara vez vale la pena a menos que un cliente pague por ello. ### ¿Cuántos SLO debe tener un servicio? Dos o tres que correspondan a lo que los usuarios realmente sienten, como disponibilidad y latencia. Más que eso y nadie recuerda cuál impulsa las decisiones.