¿Qué significa de verdad un uptime del «99,9%»? Parece casi perfecto, pero esconde un dato sorprendente: más de 43 minutos de indisponibilidad permitida cada mes. ¿Y el «99,99%»? Apenas 4 minutos. Esta calculadora traduce un objetivo SLA de uptime en lo que cuenta de verdad: cuánto downtime (tiempo de indisponibilidad) se permite en un periodo dado, cuánto has consumido ya (el error budget), el uptime efectivo alcanzado y el coste económico del downtime. Introduce el objetivo SLA (por ejemplo 99,9%), el periodo en días, el downtime observado (con el eventual mantenimiento planificado a excluir) y el coste por minuto, y obtienes el presupuesto de downtime permitido, el uptime efectivo, el porcentaje de error budget consumido y el coste. Es paramétrica y neutra de moneda: funciona con cualquier objetivo, cualquier periodo y cualquier moneda. Es una herramienta pensada para equipos técnicos, SRE, DevOps, responsables de servicios cloud y cualquiera que deba entender, negociar o cumplir un compromiso de disponibilidad — un tema universal en la ingeniería de sistemas modernos.

Qué es un SLA de uptime

Un SLA (Service Level Agreement) es un acuerdo sobre el nivel de servicio, y en el mundo de los sistemas IT el parámetro más común es el uptime (o disponibilidad, availability): el porcentaje de tiempo en que un servicio está operativo y accesible, en un periodo dado. Un uptime del 99,9% significa que el servicio está disponible el 99,9% del tiempo; el restante 0,1% es downtime, es decir indisponibilidad. Los SLA de uptime se expresan casi siempre en «nueves»: 99% («dos nueves»), 99,9% («tres nueves»), 99,99% («cuatro nueves»), 99,999% («cinco nueves»). Más nueves, más alta la disponibilidad prometida — y más difícil y costosa de garantizar. Un SLA puede ser interno (un objetivo que un equipo se da) o contractual (un compromiso hacia los clientes, a menudo con penalizaciones si no se cumple). El punto crucial, y a menudo subestimado, es que una pequeña diferencia en porcentaje corresponde a una diferencia enorme en tiempo de downtime permitido. Entender esta traducción — de porcentaje a minutos reales — es el primer paso para gestionar, negociar o cumplir un compromiso de disponibilidad de forma consciente.

Cómo se calcula el downtime permitido

El cálculo de base es simple. El downtime permitido (o «error budget» en minutos) es la fracción de tiempo de indisponibilidad que permite el SLA, aplicada a la duración del periodo. Primero se convierte el periodo en minutos: días × 24 × 60. Luego se multiplica por la cuota de downtime permitida, es decir uno menos el objetivo dividido por 100. En fórmula: D_max = (1 − s/100) × P, donde D_max es el downtime permitido, s el objetivo SLA en porcentaje, P los minutos totales del periodo. Por ejemplo, con un objetivo del 99,9% sobre 30 días: P = 43.200 minutos, la cuota permitida es 0,1% = 0,001, así que D_max = 43,2 minutos. La calculadora hace exactamente esto, y luego compara el downtime que has observado efectivamente con este presupuesto, calculando cuánto has consumido (el error budget consumido), el uptime efectivo alcanzado y el coste económico del downtime. También puedes excluir el mantenimiento planificado, que muchos SLA no contabilizan. Es la herramienta para pasar del objetivo abstracto a los números concretos: cuánto margen tienes, si estás cumpliendo el compromiso, y qué te cuesta la indisponibilidad.

La matemática de los «nueves»

El corazón de la disponibilidad es una matemática despiadada: cada cifra «nueve» adicional reduce el downtime permitido diez veces. La tabla muestra cuánto downtime corresponde a los objetivos más comunes, sobre base mensual (30 días) y anual:

La progresión es impresionante. Pasar del 99% al 99,9% reduce el downtime anual de más de 3 días a menos de 9 horas; del 99,9% al 99,99%, de casi 9 horas a menos de una hora; del 99,99% al 99,999%, a poco más de 5 minutos al año. Pero hay una cara oscura: cada nueve adicional cuesta de forma desproporcionada. Pasar de tres a cuatro nueves requiere típicamente redundancia, automatización, sistemas de failover, monitorización avanzada, equipos on-call — inversiones que crecen mucho más rápido que la reducción del downtime. Por eso la elección del objetivo no es «más nueves siempre es mejor»: es un equilibrio entre el valor de una mayor disponibilidad y su coste creciente. La calculadora te ayuda a ver esta realidad en números concretos para tu periodo específico.

La descomposición del cálculo

La tabla muestra la descomposición en el caso por defecto — objetivo SLA 99,9%, periodo 30 días, downtime total observado 25 minutos, mantenimiento planificado excluido 5 minutos, coste 500 por minuto:

El cuadro es claro. Con un objetivo del 99,9% sobre 30 días, tienes un presupuesto de 43,2 minutos de downtime. De los 25 minutos observados, 5 eran mantenimiento planificado (excluido), así que se contabilizan 20: el 46% del presupuesto. Estás por tanto ampliamente dentro del SLA, con un uptime efectivo del 99,954% y más de la mitad del presupuesto todavía disponible. El downtime contabilizado costó unos 10.000. Cambia los parámetros con tus números: verás enseguida si estás cumpliendo el compromiso y cuánto margen te queda.

El error budget: una forma diferente de pensar la fiabilidad

Uno de los conceptos más potentes introducidos por la ingeniería de la fiabilidad (SRE, Site Reliability Engineering) es el error budget. La idea es contraintuitiva pero genial: si el objetivo es el 99,9%, entonces el 0,1% de downtime no es un fallo a evitar a toda costa, sino un «presupuesto» que gastar. Este presupuesto de indisponibilidad se puede «gastar» de forma productiva: para lanzar nuevas funcionalidades (que conllevan riesgo), hacer mantenimiento, experimentar, o simplemente absorber los imprevistos. Mientras estés dentro del presupuesto, va bien. Esto cambia radicalmente la perspectiva. En lugar de tratar cada minuto de downtime como una catástrofe (lo que llevaría a bloquear todo cambio por miedo), el error budget crea un equilibrio entre fiabilidad e innovación. Si el presupuesto se consume demasiado rápido, es la señal para frenar los lanzamientos y concentrarse en la estabilidad; si no se consume casi nunca, quizá se está «sobre-invirtiendo» en fiabilidad a costa de la velocidad de desarrollo. El error budget se convierte así en una herramienta de gobierno compartida entre quien desarrolla (quiere lanzar rápido) y quien opera (quiere estabilidad), alineando los incentivos sobre un número medible. La calculadora muestra justo cuánto error budget has consumido: es el dato clave para estas decisiones.

Uptime vs downtime: la conversión

Uptime y downtime son dos caras de la misma moneda, pero pensarlos por separado ayuda a evitar errores. El uptime es el porcentaje de tiempo en que el servicio funciona; el downtime es el tiempo (en minutos, horas, días) en que no funciona. La relación es: downtime = (1 − uptime%) × periodo. El error más común es razonar solo en porcentaje, donde las diferencias parecen pequeñas («99,9% y 99,99% son casi iguales»), cuando en términos de tiempo real son enormes (43 minutos frente a 4 al mes, un factor de diez). Otro punto importante es que el uptime siempre debe referirse a un periodo: el 99,9% sobre un mes y el 99,9% sobre un año permiten downtimes totales muy diferentes en valor absoluto. Y está la cuestión de qué se mide: ¿el uptime del servidor? ¿Del servicio percibido por el usuario? ¿De un solo componente o de toda la cadena? Un servicio puede tener los servidores «arriba» pero ser de hecho inutilizable por un problema aguas abajo. La calculadora trabaja sobre el concepto general de disponibilidad del servicio en el periodo que indiques; la definición precisa de qué constituye «downtime» es, en la práctica, uno de los puntos más importantes (y discutidos) de todo SLA.

Mantenimiento planificado y exclusiones

Un detalle que marca una gran diferencia es qué excluye el SLA del conteo del downtime. La más común es el mantenimiento planificado (planned maintenance): ventanas de intervención comunicadas de antemano, durante las cuales el servicio puede estar indisponible sin que esto cuente como violación. Muchos SLA prevén estas ventanas, típicamente en horarios de bajo uso. Otras exclusiones frecuentes conciernen a: causas de fuerza mayor (eventos excepcionales fuera del control del proveedor), problemas atribuibles al cliente (por ejemplo configuraciones erróneas del lado del usuario), interrupciones de terceros (proveedores externos, conectividad), y ataques o eventos de seguridad en ciertas condiciones. La consecuencia práctica es que el downtime «real» percibido y el downtime «contabilizado» a efectos del SLA pueden diferir, incluso mucho. En la calculadora, el campo «mantenimiento planificado excluido» te permite restar esta cuota del downtime total, para calcular el downtime efectivamente contabilizado. Es un recordatorio importante: cuando se valora o se negocia un SLA, las definiciones y exclusiones cuentan tanto como el porcentaje. Un SLA del 99,99% con muchas exclusiones puede, en la práctica, ofrecer menos que uno del 99,9% con pocas exclusiones. Lee siempre las cláusulas con atención.

El coste del downtime: el impacto en el negocio

Detrás de cada minuto de downtime hay un coste, y cuantificarlo es esencial para tomar decisiones racionales sobre la fiabilidad. El coste del downtime depende del tipo de servicio, pero incluye típicamente: los ingresos perdidos (para un e-commerce o un servicio de pago, cada minuto de indisponibilidad son ventas no realizadas), la productividad perdida (si el servicio se usa internamente, los empleados no pueden trabajar), los costes de recuperación y respuesta (el equipo que interviene, las horas extra, el análisis post-incidente), las eventuales penalizaciones contractuales hacia los clientes, y — a menudo el más insidioso — el daño reputacional y la pérdida de confianza. Algunos servicios tienen costes de downtime enormes, donde cada minuto vale miles o decenas de miles; otros son más tolerantes. Conocer el coste por minuto es crucial por dos motivos. Primero: permite justificar las inversiones en fiabilidad (si un minuto de downtime cuesta X, ¿cuánto vale reducir el downtime esperado?). Segundo: ayuda a elegir el objetivo correcto, equilibrando el coste de una mayor disponibilidad con el coste del downtime que se evitaría. En la calculadora, introduciendo el coste por minuto, ves el impacto económico del downtime contabilizado — un dato concreto para dialogar con el negocio, no solo con los técnicos. Esta es una estimación paramétrica, no un compromiso contractual.

SLA hacia los clientes: penalizaciones y créditos de servicio

Cuando un SLA es contractual — es decir un compromiso del proveedor hacia los clientes — la violación tiene consecuencias económicas directas, típicamente en forma de penalizaciones o, más a menudo, de créditos de servicio (service credits). El mecanismo clásico funciona así: si el uptime baja del umbral prometido, el cliente tiene derecho a un reembolso igual a un porcentaje de la cuota pagada, creciente al empeorar la violación. Por ejemplo, un SLA podría prever un crédito del 10% de la cuota mensual si el uptime baja del 99,9%, del 25% bajo el 99%, y así sucesivamente. Es importante entender algunos aspectos prácticos. Los créditos de servicio son a menudo el único remedio previsto (el cliente no puede pedir más, salvo casos particulares), y suelen estar limitados a un porcentaje máximo de la cuota. Además casi siempre deben ser solicitados activamente por el cliente dentro de ciertos plazos, no acreditados automáticamente. Desde el punto de vista del proveedor, los créditos son un incentivo para cumplir el SLA, pero raramente cubren el daño real del cliente (que puede ser muy superior a la cuota). Desde el punto de vista del cliente, un SLA con créditos generosos da una garantía, pero hay que leerlo con atención: el porcentaje prometido, las exclusiones, los límites y los procedimientos marcan la diferencia entre una tutela real y una formal. La calculadora estima el downtime y su coste técnico; el valor de los créditos depende de las cláusulas contractuales específicas.

Los SLA en el mundo de los servicios cloud

Los SLA de uptime son omnipresentes en el mundo de los servicios cloud y digitales. La tabla resume algunos niveles típicos (indicativos, cada proveedor tiene sus propias condiciones):

En el mundo real, los proveedores de servicios cloud (infraestructura, plataformas, software) ofrecen SLA diferenciados por tier de servicio: cuanto más se paga, más alto es el uptime garantizado. Es un tema universal e internacional: las mismas lógicas valen en todas partes, porque la matemática de la disponibilidad no depende del país o de la moneda. Algunas observaciones prácticas. Los SLA más altos (cuatro o cinco nueves) suelen estar reservados a los tiers premium y conllevan condiciones más estrictas. Muchos SLA se refieren a componentes individuales (por ejemplo el cómputo, o el almacenamiento), mientras que la disponibilidad end-to-end percibida por el usuario depende de la cadena de todos los componentes — y, como veremos, las dependencias se multiplican bajando el uptime global. Las definiciones de «downtime», las exclusiones y los créditos varían mucho entre proveedores. La calculadora es paramétrica justo para adaptarse a cualquier SLA: introduce el objetivo y el periodo del servicio que te interesa, y obtienes una estimación concreta. Esta es una estimación paramétrica, no un compromiso contractual.

Cuánto uptime hace falta de verdad: elegir el objetivo

Una de las decisiones más importantes, y más a menudo tomada mal, es la elección del objetivo de uptime. El instinto es apuntar al máximo («¡queremos cinco nueves!»), pero es casi siempre el enfoque equivocado. El objetivo correcto depende de un equilibrio entre el valor de una mayor disponibilidad y su coste. Algunas preguntas guía. ¿Cuál es el coste real del downtime para este servicio? Un servicio interno de reportes y una plataforma de pagos tienen necesidades muy diferentes. ¿Cuál es la tolerancia de los usuarios? Algunos servicios pueden permitirse breves interrupciones sin consecuencias; otros no. ¿Cuál es el coste de añadir un nueve? Como se ha visto, crece rápidamente. Y, crucial, ¿el objetivo prometido es realista para la arquitectura actual? Prometer un uptime que no se puede mantener es contraproducente: genera violaciones, penalizaciones y pérdida de confianza. La regla de oro del SRE es que la fiabilidad debería ser «suficientemente alta» para los usuarios, no «máxima» en absoluto: más allá de cierto punto, los usuarios ni siquiera perciben la mejora, pero el coste sigue creciendo. La calculadora ayuda a hacer concreta esta elección: prueba diferentes objetivos y periodos, mira el downtime permitido y el coste, y encuentra el punto de equilibrio correcto para tu caso. Esta es una estimación paramétrica, no un compromiso contractual.

Límites del cálculo

Esta calculadora proporciona una estimación paramétrica de la relación entre objetivo de uptime, downtime permitido, error budget y coste, no un compromiso contractual ni una medida oficial de la disponibilidad. El cálculo asume una definición «simple» de downtime como tiempo de indisponibilidad en el periodo, mientras que en la práctica la definición de downtime a efectos del SLA es a menudo compleja: qué cuenta como «caído» (¿indisponibilidad total? ¿degradación del rendimiento? ¿errores en una parte de las solicitudes?), cómo se mide (desde dónde, con qué granularidad), y qué está excluido (mantenimiento, fuerza mayor, terceros). El modelo considera una única exclusión (el mantenimiento planificado), mientras que los SLA reales prevén muchas. No calcula los créditos de servicio efectivos (que dependen de las cláusulas contractuales), no modela el uptime acumulativo de varios componentes en serie o en paralelo, no considera la distribución temporal del downtime (una única interrupción larga y muchas breves tienen impactos diferentes incluso con los mismos minutos totales), ni el coste real del downtime (que aquí es una simple multiplicación, mientras que en la realidad varía con el momento, la duración y el tipo de servicio). Usa el resultado para entender la lógica de la disponibilidad — en particular la matemática de los «nueves» y el concepto de error budget — y para estimaciones de orden de magnitud, pero para compromisos contractuales y medidas precisas confía en herramientas de monitorización dedicadas y en una definición rigurosa del SLA. Esto no es una garantía de servicio.

SLA, SLO y SLI: quién hace qué

En el mundo de la fiabilidad de los servicios se usan tres siglas que se confunden fácilmente pero tienen roles distintos: SLA, SLO y SLI. La tabla las aclara:

La relación entre las tres es jerárquica y lógica. El SLI (Service Level Indicator) es la medida: un número concreto que describe el comportamiento del servicio, por ejemplo el porcentaje de solicitudes servidas correctamente o dentro de cierto tiempo. El SLO (Service Level Objective) es el objetivo que el equipo se fija sobre ese indicador: «queremos que el SLI esté por encima del 99,95%». Es un target interno, la referencia para el error budget. El SLA (Service Level Agreement) es el compromiso contractual hacia los clientes, con consecuencias (penalizaciones, créditos) si se viola. Una buena práctica es mantener el SLO más estricto que el SLA: si te comprometes contractualmente al 99,9% (SLA) pero internamente apuntas al 99,95% (SLO), tienes un margen de seguridad — cuando sobrepasas el objetivo interno, todavía tienes espacio antes de violar el compromiso externo. Confundir estos conceptos lleva a errores: prometer a los clientes (SLA) el mismo nivel que se espera alcanzar internamente (SLO) es arriesgado. La calculadora trabaja sobre el concepto general de objetivo de disponibilidad; puedes usarla tanto para un SLO interno como para un SLA contractual. Esta es una estimación paramétrica, no un compromiso contractual.

Uptime acumulativo: por qué cuentan las dependencias

Un aspecto contraintuitivo y crucial es que el uptime de un servicio compuesto por varios componentes en serie (donde cada uno debe funcionar para que el todo funcione) es inferior al de los componentes individuales: las disponibilidades se multiplican. La tabla muestra el efecto, suponiendo que cada dependencia tenga un uptime del 99,9%:

La matemática es despiadada: si tu servicio depende de diez componentes, cada uno con un excelente 99,9%, la disponibilidad end-to-end percibida por el usuario baja a cerca del 99,0% — con más de 7 horas de downtime al mes, un orden de magnitud peor que el componente individual. Esto explica un fenómeno común: un servicio puede usar proveedores cloud que prometen cada uno un uptime altísimo, y aun así ofrecer a sus propios usuarios una disponibilidad netamente inferior, porque la cadena de dependencias multiplica los pequeños downtimes de cada uno. Las contramedidas son lo opuesto de la serie: la redundancia en paralelo (tener componentes alternativos que se sustituyen mutuamente) aumenta la disponibilidad en lugar de reducirla, porque el sistema sigue arriba mientras al menos uno funcione. Diseñar para la fiabilidad significa por tanto minimizar las dependencias críticas en serie y añadir redundancia donde cuenta. La calculadora estima el uptime de un solo servicio o componente; para el uptime acumulativo de una arquitectura compleja hay que modelar la cadena de dependencias. Esta es una estimación paramétrica, no un compromiso contractual.

Cómo mejorar el uptime: redundancia y resiliencia

Aumentar el uptime — es decir añadir «nueves» — requiere inversiones en redundancia y resiliencia, con un coste creciente. Las palancas principales. La redundancia: eliminar los «single points of failure» teniendo componentes duplicados (servidores, bases de datos, zonas geográficas) que se sustituyen en caso de fallo. El failover automático: mecanismos que mueven el tráfico a un componente sano sin intervención manual, reduciendo drásticamente el tiempo de recuperación. La monitorización y la alerta: detectar los problemas rápido (idealmente antes que los usuarios) para intervenir enseguida. La automatización de la respuesta: procedimientos automáticos que gestionan los escenarios comunes sin espera humana. La reducción del radio de impacto (blast radius): diseñar el sistema de modo que un fallo en una parte no derribe el todo. Los tests de resiliencia (incluso el «chaos engineering», que introduce fallos controlados para verificar la robustez). Y, no menos importante, los procesos: procedimientos de respuesta a incidentes, equipos on-call, análisis post-incidente sin culpabilizaciones para aprender de los errores. El punto clave es que cada nueve adicional cuesta más que el anterior: pasar del 99,9% al 99,99% requiere típicamente un esfuerzo mucho mayor que del 99% al 99,9%. Por eso la elección del objetivo hay que hacerla con el coste del downtime en la mano, como muestra la calculadora. Esta es una estimación paramétrica, no un compromiso contractual.

El papel de la monitorización: medir el uptime real

Un uptime declarado vale poco sin una monitorización seria que lo mida. Y aquí emergen preguntas sutiles pero decisivas: ¿desde dónde se mide la disponibilidad? Un servicio puede resultar «arriba» desde el data center pero «caído» para un usuario en otra región, por un problema de red. ¿Qué se mide exactamente? ¿La simple accesibilidad del servidor, o el hecho de que el servicio responda correctamente y en tiempo razonable? Un servidor que responde pero con errores, o lentísimo, está técnicamente «arriba» pero de hecho es inutilizable. ¿Con qué frecuencia se muestrea? Un control cada cinco minutos puede «perder» una interrupción de dos minutos. Por eso la monitorización moderna combina varios enfoques: controles externos desde varias localizaciones (para ver el servicio como lo ven los usuarios), monitorización interna de los componentes, y cada vez más la medida basada en la experiencia real de los usuarios (cuántas solicitudes tienen éxito, con qué latencia). La medida del uptime es por tanto ella misma una elección de diseño: definir el SLI (el indicador) de modo que capture lo que cuenta para los usuarios es la mitad del trabajo. Un uptime «del 99,9%» mal medido puede esconder una experiencia de usuario mucho peor. La calculadora trabaja sobre el downtime que introduces; la calidad de ese dato depende de la calidad de tu monitorización. Esta es una estimación paramétrica, no un compromiso contractual.

Preguntas que hacer antes de firmar un SLA

Seas el proveedor que ofrece un SLA o el cliente que lo valora, algunas preguntas son esenciales. ¿Cuál es la definición exacta de «downtime»? ¿Indisponibilidad total, degradación, errores en una parte de las solicitudes? Es el punto más importante y más a menudo ambiguo. ¿Desde dónde y cómo se mide la disponibilidad, y con qué frecuencia? ¿Qué está excluido del conteo — mantenimiento planificado (¿con cuánto preaviso?), fuerza mayor, problemas de terceros, causas del cliente? ¿Sobre qué periodo está definido el SLA (mensual, anual)? A igualdad de porcentaje, un periodo más corto es más severo. ¿Cuáles son los remedios en caso de violación — créditos de servicio? ¿De qué magnitud, con qué límites y cómo se solicitan? ¿El uptime se refiere al componente individual o al servicio end-to-end? Y, para el cliente: ¿el SLA cubre de verdad mi riesgo, o los créditos son simbólicos respecto al daño que sufriría? Para el proveedor: ¿el objetivo prometido es realista para mi arquitectura, o me estoy exponiendo a violaciones continuas? Estas preguntas muestran que un SLA es mucho más que la sola percentaje de uptime: las definiciones, las exclusiones y los remedios marcan la diferencia entre una tutela real y una de fachada. La calculadora te ayuda a traducir el porcentaje en downtime concreto y a razonar sobre el coste; para la valoración contractual completa, lee con atención cada cláusula. Esta es una estimación paramétrica, no un compromiso contractual.

Preguntas frecuentes

¿Cuánto downtime permite un uptime del 99,9%?

Unos 43,2 minutos al mes (sobre 30 días) o unas 8,77 horas al año. El 99,9% («tres nueves») significa que el 0,1% del tiempo puede ser indisponibilidad. Parece poco, pero traducido a minutos reales es más de lo que muchos esperan. La calculadora convierte cualquier objetivo SLA en el downtime permitido para el periodo que indiques, mostrando la matemática de los «nueves».

¿Qué datos necesito para usar la calculadora?

Cinco valores: el objetivo SLA de uptime (%), el periodo en días, el downtime total observado en minutos, el eventual mantenimiento planificado a excluir y el coste del downtime por minuto. La calculadora devuelve el downtime permitido (error budget), el uptime efectivo, el porcentaje de error budget consumido y el coste del downtime contabilizado.

¿Cómo se calcula el downtime permitido?

Se convierte el periodo en minutos (días × 1440) y se multiplica por la cuota de downtime permitida, es decir uno menos el objetivo dividido por 100. En fórmula: D_max = (1 − s/100) × P, donde s es el objetivo SLA y P los minutos del periodo. Por ejemplo, 99,9% sobre 30 días: 43.200 × 0,001 = 43,2 minutos. La calculadora hace esto y compara tu downtime observado con el presupuesto.

¿Qué es la matemática de los «nueves»?

Es el hecho de que cada cifra «nueve» adicional de uptime reduce el downtime permitido diez veces. El 99% permite ~7,2 horas al mes, el 99,9% ~43 minutos, el 99,99% ~4 minutos, el 99,999% ~26 segundos. Pequeñas diferencias en porcentaje corresponden a diferencias enormes en tiempo real — y obtener cada nueve adicional cuesta de forma desproporcionada (redundancia, automatización, failover).

¿Qué es el error budget?

Es un concepto SRE (Site Reliability Engineering): si el objetivo es 99,9%, el 0,1% de downtime no es un fallo a evitar a toda costa, sino un «presupuesto» que gastar. Puedes «gastarlo» para lanzar nuevas funcionalidades, hacer mantenimiento, absorber imprevistos. Mientras estés dentro del presupuesto, va bien. Es una herramienta de gobierno que equilibra fiabilidad e innovación: si lo consumes demasiado rápido, frena los lanzamientos.

¿El cálculo depende de la moneda?

No. La calculadora es neutra de moneda: introduce el coste del downtime por minuto en tu moneda y obtienes resultados coherentes (el downtime es en minutos, el uptime en porcentaje). Es un tema universal e internacional, porque la matemática de la disponibilidad no depende del país o de la moneda. Las mismas lógicas valen en todas partes.

¿Qué excluye un SLA del conteo del downtime?

La más común es el mantenimiento planificado (ventanas comunicadas de antemano). Otras exclusiones frecuentes: causas de fuerza mayor, problemas atribuibles al cliente, interrupciones de terceros (proveedores externos, conectividad), ciertos eventos de seguridad. El downtime «real» percibido y el «contabilizado» a efectos del SLA pueden diferir mucho. En la calculadora puedes excluir el mantenimiento planificado; las demás exclusiones dependen del contrato.

¿Qué son los créditos de servicio (service credits)?

Son el remedio típico cuando un proveedor viola un SLA contractual: el cliente tiene derecho a un reembolso igual a un porcentaje de la cuota, creciente al empeorar la violación. Son a menudo el único remedio previsto, limitados a un máximo, y suelen tener que solicitarse activamente dentro de ciertos plazos. Raramente cubren el daño real del cliente. El valor depende de las cláusulas específicas.

¿Por qué cuenta el coste del downtime?

Porque permite tomar decisiones racionales. Conocer el coste por minuto ayuda a justificar las inversiones en fiabilidad (si un minuto cuesta X, ¿cuánto vale reducir el downtime?) y a elegir el objetivo correcto, equilibrando el coste de más uptime con el coste del downtime evitado. El coste incluye ingresos perdidos, productividad, recuperación, penalizaciones y daño reputacional.

¿99,99% es siempre mejor que 99,9%?

No necesariamente. Un uptime más alto es más difícil y costoso de garantizar: cada nueve adicional cuesta de forma desproporcionada. El objetivo correcto depende del coste del downtime, de la tolerancia de los usuarios y del coste de añadir un nueve. La regla SRE es que la fiabilidad debería ser «suficientemente alta» para los usuarios, no «máxima»: más allá de cierto punto los usuarios no perciben la mejora pero el coste crece.

¿El uptime debe referirse a un periodo?

Sí, siempre. El 99,9% sobre un mes y el 99,9% sobre un año permiten downtimes totales muy diferentes en valor absoluto (43 minutos frente a casi 9 horas). Por eso es importante especificar el periodo de referencia. En la calculadora introduces el periodo en días, y obtienes el downtime permitido para ese periodo específico. Verifica siempre sobre qué periodo está definido el SLA que estás valorando.

¿El resultado es fiable?

Es una estimación paramétrica de la lógica de disponibilidad, no un compromiso contractual ni una medida oficial. Asume una definición simple de downtime y una sola exclusión (mantenimiento), mientras que los SLA reales son más complejos (definición de «caído», medición, muchas exclusiones, créditos, uptime acumulativo de varios componentes). Úsala para entender la lógica de los «nueves» y del error budget y para estimaciones de orden de magnitud; para compromisos y medidas precisas usa herramientas de monitorización.

Actualizado a julio de 2026