SLA de una aplicación móvil: qué incluye y qué no

Si un SLA no dice cómo se mide ni qué pasa cuando se incumple, no es un compromiso: es una declaración de intenciones con formato de contrato. Y se ve mucho más de lo que debería. Los contratos de mantenimiento que nos llegan para revisar suelen traer una plantilla heredada de otro proyecto, con el mismo patrón: el proveedor es juez y parte, las exclusiones se comen el cómputo y nadie paga por fallar. Antes de discutir qué incluye un SLA de aplicación móvil hay que aceptar eso: el problema no es el porcentaje, es que nadie ha definido quién sostiene el cronómetro.

En Docastix el SLA se acuerda caso a caso y va escrito en la propuesta de desarrollo de apps móviles y de plataformas SaaS antes de firmar. No publicamos un nivel estándar porque no lo hay: el número que tiene sentido depende de qué sostiene tu aplicación y de cuánta redundancia estás dispuesto a pagar, y prometer lo mismo a todo el mundo es la primera señal de que nadie ha hecho el cálculo. Lo que sí es siempre igual: lo que no se puede comprobar no se puede reclamar el día que toca.

Respuesta rápida: qué incluye un SLA de aplicación móvil

Un SLA útil tiene seis piezas: disponibilidad comprometida, ventana de cobertura, tiempos de respuesta por severidad, exclusiones acotadas, medición independiente y consecuencia económica escalonada. Si falta una, has firmado una carta de intenciones. Las que más se omiten: qué cuenta como caída, quién mide y qué pasa si el número no se cumple.

Quédate con tres ideas: un 99,9% mensual son 43 minutos de caída, el tiempo de resolución no se compromete con un número cerrado y las exclusiones deciden si el porcentaje significa algo.

Los «nueves» en minutos: cuánta caída permite cada nivel

Un porcentaje de disponibilidad no dice nada hasta que lo conviertes en minutos de servicio caído.

La aritmética es comprobable: un mes de 30 días tiene 43.200 minutos y un año 525.600. El 0,1% de 43.200 son 43,2 minutos; el 0,1% de 525.600 son 525,6, casi nueve horas. Ese salto es lo que nadie ve: el 99,9% que suena impecable en un mes admite una jornada laboral entera de caída al año.

Dos matices mueven el número. La ventana de cómputo: con mes natural, un 99,9% permite 40 min 19 s en un febrero de 28 días —41 min 46 s si es bisiesto— y 44 min 38 s en un mes de 31. Y mensual frente a anual: un compromiso anual deja concentrar toda la caída en un mal día de noviembre sin incumplir nada.

Tres nueves son un punto de partida razonable para una app de negocio bien construida. Cuatro nueves, 4 minutos y 19 segundos al mes, son menos de lo que dura un despliegue mal planificado: exigirlos implica redundancia, despliegues sin corte y guardia real. El nivel que necesitas lo marca lo que cuesta cada minuto caído, no lo que suena bien en una propuesta. En el caso de PropPilot, publicado en junio de 2026, la primera respuesta a un lead pasó de horas a menos de 60 segundos, 24/7 en cuatro regiones: con ese compromiso delante, un rato sin servicio de madrugada es un lead frío.

Los grandes se comprometen en esa franja. El SLA de cómputo de AWS fija «at least 99.99%» por región, pero solo con «all running instances deployed concurrently across two or more AZs», y baja a «at least 99.5%» para una instancia suelta. El SLA de Compute Engine de Google Cloud da 99,99% con instancias en varias zonas en su nivel Premium, salvo en las regiones de México y Estocolmo; para una instancia común se queda en 99,9%. Microsoft pide dos o más máquinas virtuales en un conjunto de disponibilidad para llegar al 99,95%. El número no sale del compromiso comercial: sale de cuánta redundancia has pagado.

Los tres números que la gente confunde

Disponibilidad. Qué porcentaje del tiempo responde el servicio. Se mide sobre componentes observables de forma continua y que tu equipo controla: backend, API, panel web. Los cierres y fallos de la app instalada también importan, pero se siguen con otras métricas de calidad; el porcentaje del SLA suele aplicarse al servicio que la sostiene.

Tiempo de respuesta. Cuánto tarda alguien en confirmar que ha visto el problema, lo ha clasificado y está en ello. Es el más fácil de comprometer con honestidad, porque depende de la cobertura, la monitorización y el escalado del propio equipo, no de haber encontrado ya la causa. Y es el que se nota: entre un sábado tranquilo y uno horrible media que contesten en veinte minutos.

Tiempo de resolución. Cuánto tarda en estar arreglado. Aquí está la trampa: hay fallos cuya causa está en un tercero, en un dato corrupto o en un dispositivo concreto. Quien firma «resolución en 4 horas para todo» o bien cuenta con las exclusiones, o bien ha metido en la cuota un colchón que pagas cada mes aunque no pase nada. Es lo mismo que encarece un precio cerrado sobre alcance difuso: garantizar lo que no controlas se cobra por adelantado.

En su lugar se comprometen tres cosas medibles: esfuerzo continuado hasta mitigar el incidente crítico, actualizaciones cada X con cadencia escrita (cada hora en crítico, cada jornada en el resto) y una ruta de escalado con nombres y teléfonos. Y separa mitigar de corregir en origen: compromete solo lo primero.

Severidades: las define el impacto en tu negocio, no el proveedor

Si quien decide que algo es «crítico» es quien tendrá que levantarse a arreglarlo, no tienes un SLA: tienes un sistema de honor. La severidad se define en el contrato, por impacto de negocio y con ejemplos escritos.

Los dos ejemplos que más discusiones evitan son «no se puede pagar» y «no se puede entrar»: escríbelos literalmente como S1. Cualquier redacción que permita defender que un checkout caído es «prioridad alta» porque el resto funciona está mal escrita a propósito. Y añade un mecanismo de desacuerdo: si tú clasificas S1 y el proveedor discrepa, se trata como S1 mientras se resuelve.

Las exclusiones: aquí se juega el SLA entero

Hay exclusiones razonables —sin ellas nadie sensato firma— y exclusiones que vacían el compromiso.

Ventanas de mantenimiento programado. Razonable: anunciada con 72 horas de antelación, en horario de bajo uso y con tope mensual, por ejemplo cuatro horas. Abusiva: «el mantenimiento programado queda excluido del cómputo», sin tope ni preaviso. Con esa frase se puede tener el servicio parado veinte horas al mes y presentar un informe al 100%.

Caídas de terceros. Tu equipo no controla que se caiga la pasarela de pago, el proveedor de push o el hosting. Excluirlo es legítimo; desentenderse no: exige detección, aviso en el mismo plazo que un incidente propio y un plan de degradación. Y mira hacia arriba en la cadena. El SLA de Supabase —que solo aplica a sus clientes Enterprise, así que en los planes de pago normales no hay compromiso de disponibilidad: el plan Team trae SLA de soporte, que es otra cosa— promete un 99,9% mensual pero excluye a sus «Third-Party Vendors»: AWS, Cloudflare, GCP, Azure y GitHub. El SLA de Firebase cubre Hosting y Realtime Database con un 99,95% y deja fuera Cloud Messaging, el que entrega tus notificaciones push. Y Stripe no garantiza un servicio «uninterrupted or error-free»: lo presta «as is».

Fuerza mayor. Razonable con su definición jurídica. Abusiva cuando se estira hasta cubrir «picos de tráfico inesperados»: un pico no es fuerza mayor, es capacidad mal dimensionada, y si tu producto tiene estacionalidad eso se pacta antes.

Uso fuera de lo previsto. Razonable excluir el uso contra la documentación, versiones con un año sin actualizar o cambios hechos por otro equipo. Abusivo cuando permite descartar cualquier incidencia alegando «configuración del cliente»: quien invoca la exclusión la justifica por escrito.

Filtro final: suma las horas que podrían salir del cómputo por exclusiones. Si superan lo que el propio SLA permite caer, el número es decorativo.

Cómo se mide y quién mide

Si el proveedor mide, calcula, redacta el informe y decide si se ha cumplido, no hay compromiso: hay autoevaluación.

• Monitorización externa. Sondas fuera de la infraestructura medida, desde dos ubicaciones como mínimo, ejercitando el flujo crítico (autenticar, leer, escribir), no un ping. Con panel accesible para ti.
• Definición de caída. Un endpoint que tarda doce segundos está caído para el usuario aunque devuelva un 200: pacta un umbral de latencia, no solo errores 5xx.
• Granularidad del muestreo. Un sondeo cada cinco minutos no detecta una caída de tres. Si comprometes 99,95% —21 minutos al mes— y mides cada cinco, el margen de error es la cuarta parte de tu presupuesto de caída.
• Informe mensual. Disponibilidad calculada, incidentes con severidad, marcas de detección, respuesta y cierre, exclusiones justificadas y crédito devengado. Que llegue solo.
• Datos accesibles. Registros y métricas en cuentas tuyas o exportables. Si el día de la discusión los datos solo están en el sistema del proveedor, la discusión ya está decidida.

Es la misma infraestructura que detecta un patrón raro de peticiones, y los plazos regulatorios de notificación corren desde que alguien se entera: cómo manejar la seguridad en el desarrollo de aplicaciones móviles.

Penalizaciones: crédito realista frente a indemnización cara

Lo sensato es un crédito en la siguiente factura, escalonado según lo lejos que quede el proveedor del compromiso. Los grandes lo hacen así: AWS acredita un 10% por debajo del 99,99% y desde el 99%, un 30% desde el 95% y por debajo del 99%, y un 100% por debajo del 95%; Google Cloud usa 10%, 25% y 100%; Supabase, en ese mismo SLA de Enterprise, escalona 10%, 15%, 20% y 30%, con tope del 20% de lo pagado en los doce meses anteriores.

El crédito se calcula sobre la cuota del servicio, no sobre tu lucro cesante, y suele haber que reclamarlo dentro de plazo o caduca: escribe que se aplique de oficio cuando el informe mensual muestre incumplimiento.

La parte incómoda: exigir indemnizaciones grandes sale caro y no protege más. El proveedor no absorbe ese riesgo, lo mete en el precio de partida como colchón, igual que en un presupuesto a precio cerrado. Pagas un seguro cada mes por un siniestro improbable y, cuando llega, un tope de responsabilidad lo deja en poco más que el crédito.

La cláusula que de verdad importa casi nunca está: el incumplimiento reiterado como causa de resolución sin penalización para el cliente. Redáctala con números —tres meses incumplidos en seis, o dos consecutivos por debajo de un mínimo— y con consecuencias: terminar sin coste, devolución proporcional de lo anticipado y traspaso ordenado con repositorios, infraestructura y credenciales. Lo que le duele a un proveedor no son cien euros de crédito, es perder la cuenta. Para ejercerla, la propiedad y la salida deben estar resueltas antes, algo que tratamos en cómo elegir el mejor equipo para desarrollar tu app. El SLA cubre qué pasa mientras tu partner está ahí y no responde; si desaparece, la conversación es la del escrow de código fuente.

Qué SLA necesitas de verdad según lo que tengas

Aquí se tira más dinero que en ninguna otra parte. Una herramienta interna que usan treinta personas no necesita 24/7: pagarlo es comprar una guardia que nadie activará un domingo. Al revés también pasa, y hay plataformas que facturan a diario cubiertas por un «mejor esfuerzo en horario de oficina».

La regla para decidir: calcula cuánto te cuesta una hora de caída en el peor momento del año. Si la respuesta es «nada, la gente trabaja en otra cosa», estás en la primera fila y lo demás es gasto. Si es «se paran los repartos» o «no cobramos», estás en las dos últimas y ahorrar ahí es la peor decisión disponible.

Esa tabla es para ordenar la conversación, no para copiarla en un contrato: son puntos de partida orientativos para calcular el coste de la caída, no un catálogo. Lo que sí se puede dar por bueno es de dónde sale el coste, y lo desglosan cuánto cuesta mantener una app y cuánto cuesta hacer una app: lo que encarece un SLA es la ventana horaria, porque pasar de horario laboral a 24/7 implica pagar guardias que se pagan estén o no sonando los avisos. Los nueves altos, en cambio, se pagan en arquitectura redundante y no en la cláusula.

Ese post decía que la cuota fija mensual «compra disponibilidad». Conviene ser literal con lo que eso significa, se lo pagues a quien se lo pagues: un número, una ventana horaria, un plazo de respuesta por severidad y un informe que lo demuestre. Sin esas cuatro cosas escritas, la cuota compra buena voluntad.

Qué preguntar antes de firmar

• ¿Qué disponibilidad comprometes, sobre qué componentes y con qué ventana de cómputo?
• ¿Qué cuenta exactamente como caída? ¿Hay umbral de latencia o solo errores?
• ¿Quién mide, con qué herramienta y cada cuánto? ¿Tengo acceso al panel?
• ¿Quién está de guardia fuera de horario para un incidente crítico?
• ¿Cómo se clasifican las severidades y qué pasa si no estamos de acuerdo?
• ¿Cuántas horas de mantenimiento quedan fuera del cómputo y con cuánto preaviso?
• ¿Qué crédito se aplica por incumplimiento, se aplica de oficio y hay tope?
• ¿A partir de qué incumplimiento reiterado puedo resolver sin penalización?

Ninguna de las ocho es una trampa, y a casi todas se puede contestar «esto todavía no lo tenemos así». Lo que no vale es que se queden sin respuesta: cada una que no acabe escrita en la propuesta es una que se discutirá el día del incidente, cuando ya no hay margen para negociar.

Conclusión

Un SLA no es un trámite legal: es la traducción a números de quién responde un viernes a las 17:00 cuando los pagos dejan de funcionar. Y solo sirve con las seis piezas: porcentaje, ventana, plazos por severidad, exclusiones acotadas, medición que no controla el proveedor y una consecuencia que le importe.

El error más caro no es firmar un SLA flojo, es firmar uno caro que no necesitas: el coste de una hora de caída decide si te basta con horario de oficina o necesitas guardia 24/7. Si quieres que revisemos el SLA que te han propuesto, cuéntanos qué sistema tienes y quién depende de él y lo aterrizamos con cifras.