La respuesta corta
Un SLA de app móvil no es una promesa de que nada se romperá. Es un contrato sobre qué pasa cuando se rompe: en cuánto tiempo alguien responde, en cuánto se mitiga, quién decide la gravedad y qué queda expresamente fuera.
Y lo que queda fuera es la mitad del valor del documento. Un SLA que promete cosas que el proveedor no controla —empezando por el tiempo de revisión de las tiendas— no es un SLA fuerte: es uno que se va a incumplir.
Los tres tiempos que la gente confunde
Casi todas las discusiones sobre SLA vienen de mezclar estos tres:
| Tiempo | Qué significa | Se puede comprometer |
|---|---|---|
| Respuesta | Alguien cualificado ha leído la incidencia y ha empezado | Sí, con firmeza |
| Mitigación | El usuario ya no sufre el problema, aunque la causa siga ahí | Sí, por severidad |
| Resolución | La causa raíz está corregida y desplegada | Solo de forma orientativa |
Comprometer un tiempo de resolución en un contrato es un error clásico, porque la causa puede estar en un tercero, en el sistema operativo o requerir una versión nueva que tiene que pasar por revisión de la tienda. Lo que sí se compromete es responder y mitigar.
Nosotros publicamos respuesta en menos de una hora, y menos de dos horas para una incidencia crítica en producción. Son tiempos de respuesta, no de resolución, y esa distinción está en el contrato.
Severidades, con ejemplos y no con adjetivos
Una tabla de severidades solo sirve si cualquiera de las dos partes puede clasificar un caso sin discutir:
- Crítica — La app no arranca, o el flujo que genera ingresos está caído, o hay una brecha de datos. Ejemplo: el login falla para todos los usuarios.
- Alta — Una función principal no funciona y no hay alternativa. Ejemplo: no se puede completar un pago, pero el resto de la app va.
- Media — Una función secundaria falla o hay una alternativa razonable. Ejemplo: el filtro del listado no aplica bien.
- Baja — Cosmético o de baja frecuencia.
Y una regla que evita la mitad de las discusiones: quien abre la incidencia propone la severidad, el proveedor puede reclasificar por escrito y con motivo en la primera respuesta. Sin eso, todo es crítico un lunes por la mañana.
Lo que un SLA de móvil no puede cubrir
Aquí está la diferencia entre un SLA de web y uno de app, y conviene que esté escrito:
- El tiempo de revisión de las tiendas. Si el arreglo exige publicar una versión, hay un intervalo que el proveedor no controla. Se puede pedir revisión expedita, pero no garantizarla.
- Que el usuario actualice. Puedes publicar el arreglo en una hora y tener usuarios con la versión rota durante días. Por eso los SLA serios exigen que la app tenga mecanismo de actualización forzada o interruptores remotos: sin eso, el compromiso de mitigación no es cumplible.
- Caídas de terceros: la pasarela de pago, el proveedor de identidad, el servicio de notificaciones.
- Cambios del sistema operativo o de las políticas de tienda, que llegan con su propio calendario. Los requisitos de versión de plataforma tienen fechas duras —Google Play exige apuntar a API 36 desde el 31 de agosto de 2026— y adaptarse a eso es trabajo planificado, no una incidencia.
- Uso fuera de lo previsto: versiones de sistema no soportadas, dispositivos rooteados, redes corporativas que bloquean tráfico.
Un SLA que no enumera exclusiones acabará interpretándose en el peor momento posible.
Cobertura: la variable que decide el precio
- Horario laboral frente a 24×7. La diferencia no es un porcentaje del contrato: es tener o no tener guardias, y las guardias se pagan y se organizan.
- Días festivos y agosto, dicho explícitamente. La ambigüedad aquí siempre acaba mal.
- Canal de aviso único y con acuse: un teléfono de guardia o una integración, no un correo a una dirección que nadie mira a las tres de la mañana.
- Escalado: a quién se llama si el primer nivel no responde, y en cuánto tiempo.
Qué se mide, y con qué
Un SLA sin instrumentación es un pacto de caballeros. Lo mínimo:
- Crash-free sessions y crash-free users por versión.
- Disponibilidad del backend que la app consume, con su propio objetivo.
- Tiempo hasta la primera respuesta por incidencia, medido en la herramienta de tickets, no en la memoria de nadie.
- Versiones activas en el parque de usuarios, que es lo que determina si un arreglo llega de verdad.
Y quién es el árbitro del dato: si el proveedor mide y el proveedor reporta, el cliente debería tener acceso de lectura a la misma herramienta.
Créditos y penalizaciones
Se pactan, pero conviene tener claro qué compran. Un crédito del 10 % de la cuota mensual no compensa un día de caída de un producto que factura — su función real es alinear incentivos, no indemnizar.
Lo que de verdad protege es lo otro: severidades claras, canal con acuse, escalado con nombres y un compromiso de mitigación que se pueda cumplir porque la app tiene interruptores remotos.
Lo mínimo que debe llevar un SLA de app
- Definición de los tres tiempos, y cuáles se comprometen.
- Tabla de severidades con ejemplos y regla de reclasificación.
- Cobertura horaria, festivos y canal de aviso con acuse.
- Exclusiones enumeradas, incluida la revisión de tiendas.
- Métricas, herramienta y acceso del cliente a los datos.
- Escalado con personas, no con departamentos.
- Requisitos que el producto debe cumplir para que el SLA sea cumplible: actualización forzada, interruptores remotos, observabilidad.
Ese punto siete es el que casi nunca aparece y el que decide si el resto es verdad.
Nosotros firmamos SLA con guardias en proyectos de producto continuo, y lo primero que revisamos antes de comprometerlo es si la app tiene lo que hace falta para poder cumplirlo. Si tienes una app en producción sin nada de eso, la conversación empieza en una auditoría técnica, no en el contrato.
Fuente primaria para el calendario de plataforma citado, consultada el 14 de agosto de 2026: Target API level requirements for Google Play apps.
