Utiliza este runbook de incidentes para apps sin código para detectar problemas rápidamente, priorizar impacto, revertir con seguridad, comunicar con claridad y prevenir recurrencias.
Un incidente es cualquier problema inesperado que impide que la gente use tu app, la hace dolorosamente lenta o pone los datos en riesgo. En apps sin código, eso puede verse como fallos súbitos de inicio de sesión, pantallas rotas tras un cambio, automatizaciones en segundo plano que dejan de ejecutarse, errores de API o flujos “exitosos” que silenciosamente escriben valores equivocados en la base de datos.
Un runbook escrito convierte un momento estresante en una serie de acciones pequeñas y claras. Reduce suposiciones, acelera decisiones (como cuándo revertir) y ayuda a que todos compartan los mismos hechos. La mayoría de retrasos durante incidentes no son técnicos. Provienen de la incertidumbre: ¿es real? ¿quién lidera? ¿qué cambió? ¿qué decimos a los usuarios?
Esta guía es para cualquiera que toque la app cuando las cosas van mal: quienes construyen y despliegan cambios, responsables de operaciones o plataforma que gestionan despliegues y accesos, equipos de soporte que reciben los primeros reportes y propietarios de producto o negocio que valoran impacto y prioridades.
Es intencionalmente ligera, incluida para equipos que construyen sobre plataformas como AppMaster, donde puedes tener lógica visual, servicios generados y múltiples opciones de despliegue.
Cubre el ciclo completo de un incidente: detectar y confirmar un problema real, priorizar rápido, estabilizar y recuperar (incluyendo decisiones de rollback), comunicar durante la caída y luego hacer una breve revisión post-incidente para que el mismo problema sea menos probable en el futuro.
No cubre rediseños de arquitectura a largo plazo, forenseo de seguridad profundo ni procedimientos complejos de cumplimiento. Si manejas datos regulados o infraestructura crítica, añade pasos más estrictos encima de este runbook.
Los incidentes parecen caóticos cuando no sabes cómo es lo “normal”. Define tu línea base para que el equipo detecte problemas reales con rapidez. Para una app sin código, las señales tempranas suelen venir de una mezcla de salud de la plataforma, métricas de negocio y personas.
Escribe las señales que vigilarás cada día, no solo durante caídas. Las comunes incluyen uptime, tasa de errores, pantallas lentas, inicios de sesión fallidos, fallos de pago y picos en tickets de soporte o mensajes de usuarios.
Define la severidad en lenguaje llano para que cualquiera la use:
Fija objetivos de respuesta que generen impulso. Ejemplos: reconocer en 5 minutos, publicar la primera actualización en 15 minutos y buscar estabilizar en 60 minutos (aunque la solución completa tome más tiempo).
Decide roles antes de necesitarlos. Nombra quién puede declarar un incidente, quién lo lidera y quién es el respaldo si esa persona está desconectada. En equipos que usan AppMaster, suele ser la persona propietaria de la lógica de Business Process, más un respaldo que pueda manejar despliegues o exportaciones.
Por último, mantén un único lugar compartido para notas del incidente. Usa marcas de tiempo para cada acción (qué cambió, cuándo, por quién) para reconstruir la historia después sin adivinar.
Confirma el impacto antes de quedarte mirando dashboards. Haz una pregunta clara: ¿quién no puede hacer qué ahora mismo? “Soporte no puede abrir tickets” es más útil que “la app está lenta”. Si puedes, reproduce el problema usando el mismo rol y dispositivo que el usuario afectado.
Luego, determina cuán amplio es. ¿Es una cuenta, un segmento de clientes o todo el mundo? Haz particiones rápidas: región, tipo de cuenta, web vs móvil, y una función concreta vs toda la app. En herramientas sin código, algo puede parecer global cuando en realidad es una regla de permisos o una pantalla rota.
Después, revisa qué cambió. Mira 1–2 horas hacia atrás por un release, un toggle de configuración, una edición del esquema de la base de datos o una importación de datos. En plataformas como AppMaster, cambios en business processes, modelos de datos o ajustes de auth pueden afectar muchos flujos a la vez, aunque la UI parezca correcta.
Antes de culpar a tu app, descarta dependencias externas. Proveedores de email/SMS, pagos (como Stripe) e integraciones (Telegram, servicios de AWS, APIs de IA) pueden fallar o aplicar limitación de tasa. Si la app falla solo al enviar mensajes o al cobrar tarjetas, el problema raíz puede estar aguas arriba.
Usa una lista de verificación de decisión sencilla:
Una vez clasifiques severidad y alcance, puedes pasar de “¿es real?” a “¿qué hacemos primero?” sin adivinar.
Abre un registro de incidente inmediatamente. Dale un título claro que nombre el impacto al usuario, no la causa sospechada (por ejemplo, “Pago fallando para clientes de la UE”). Anota la hora de inicio (primer aviso o primer reporte). Esto será el lugar único para decisiones, marcas de tiempo y qué cambió.
Asigna roles para que el trabajo no se solape. Incluso en un equipo pequeño, nombrar dueños reduce errores bajo estrés. Como mínimo, quieres:
Escribe dos cosas: lo que sabes con certeza y tu hipótesis actual. “Conocido” puede ser: la tasa de errores subió, un endpoint específico falla, solo móvil está afectado. La hipótesis puede estar equivocada, pero debe guiar la próxima prueba. Mantén ambos actualizados conforme aprendes.
Mientras las cosas son inestables, establece una cadencia de actualización de 15 minutos. Si nada cambió, dilo. Las actualizaciones regulares frenan discusiones laterales y evitan mensajes duplicados tipo “¿novedades?”.
Elige la primera acción de contención. El objetivo es reducir daño rápido, aunque no esté claro el root cause. Movimientos típicos incluyen pausar jobs en segundo plano, deshabilitar un feature flag arriesgado, limitar tráfico a un módulo o cambiar a una configuración conocida como segura. En AppMaster, esto suele significar apagar un flujo específico en el Business Process Editor o ocultar temporalmente una ruta de la UI que provoca fallos.
Si la contención no mejora métricas dentro de una ventana de cadencia, comienza a planear el rollback en paralelo.
Una vez confirmes que es un incidente real, cambia de “encontrar el bug” a “detener la hemorragia”. Estabilizar te da tiempo. También protege a usuarios, ingresos y datos mientras investigas.
Empieza con el cambio más pequeño que reduzca el daño. La contención suele ser más rápida que una solución completa porque puedes desactivar una función nueva, pausar un workflow o bloquear una ruta de entrada arriesgada sin reconstruir todo.
Si sospechas que los datos se están corrompiendo, detén las escrituras primero. Eso puede significar desactivar formularios temporalmente, pausar automatizaciones que actualizan registros o bloquear un endpoint de API que acepta actualizaciones. Leer datos malos duele, pero escribir datos malos multiplica la limpieza.
Si los usuarios están bloqueados por el login, trata el inicio de sesión como prioridad. Revisa ajustes de autenticación y el flujo de login antes que cualquier otra cosa. Cualquier otra reparación es más lenta si los usuarios (y tu propio equipo) no pueden acceder a la app.
Si la app está lenta o da timeouts, reduce la carga y elimina rutas costosas. Apaga pantallas pesadas, pausa jobs en batch y desactiva integraciones nuevas que disparan peticiones. En AppMaster, la contención puede ser tan simple como deshabilitar un business process problemático o quitar temporalmente una acción de la UI que desencadena una cadena costosa.
Mantén las acciones deliberadas y documentadas. Bajo presión, los equipos repiten pasos o deshacen un arreglo por accidente. Anota cada cambio y el resultado.
Una secuencia simple de estabilización:
Apuntas a “seguro y usable”, no a “totalmente resuelto”. Una vez contenido el impacto, puedes diagnosticar con calma y elegir el rollback o la corrección adecuada.
Cuando algo falla, la velocidad importa, pero gana la opción más segura. Normalmente tienes tres opciones prácticas: hacer rollback, enviar una corrección hacia adelante o hacer una reversión parcial (desactivar una función dejando el resto intacto).
Primero, aclara qué significa “rollback” en tu entorno. Puede significar desplegar la versión anterior de la app, revertir un cambio de configuración o restaurar un estado de la base de datos. En plataformas como AppMaster, una “versión” puede incluir lógica backend, UI web, builds móviles y configuraciones de entorno.
Usa estas comprobaciones de riesgo para decidir si el rollback es seguro:
Establece una regla simple de ir/no ir antes de tocar nada. Elige 2–3 métricas que deban mejorar en 10–15 minutos tras la acción, como tasa de errores, éxito de login, completación de checkout o latencia de API. Si no mejoran, para y cambia de estrategia.
Planifica también cómo desharás el rollback si la versión anterior causa problemas nuevos: qué build redeplegar, qué configuración reaplicar y quién aprueba ese segundo cambio. Mantén una persona responsable de la decisión final de “ship” para no cambiar de rumbo a mitad del procedimiento.
El silencio empeora los incidentes. Usa una forma simple y repetible de mantener informadas a las personas mientras el equipo investiga.
Empieza con actualizaciones internas. Informa a quienes recibirán preguntas primero y a quienes pueden eliminar bloqueos. Sé breve y factual. Normalmente necesitas:
Para comunicaciones externas, ciñe la información a lo conocido. Evita suponer la causa o culpar a un proveedor. Los usuarios suelen querer tres cosas: confirmación, impacto y cuándo tendrán la próxima actualización.
Mantén una línea de estado consistente en todos los canales:
Si los usuarios están enfadados, reconoce primero y luego sé específico: “Sabemos que el checkout falla para algunos clientes. Estamos revirtiendo el último cambio ahora. Próxima actualización en 30 minutos.” No prometas plazos, créditos o soluciones permanentes durante el incidente.
Declara resuelto solo cuando el síntoma principal haya desaparecido y las comprobaciones clave estén limpias (logins, flujos centrales, tasas de error). Usa monitoreo cuando aplicaste una solución (p. ej., rollback o restauración) pero necesitas tiempo para vigilar repeticiones. Siempre indica qué vas a monitorear, durante cuánto y cuándo será la actualización final.
Una vez estabilizado, cambia de apagar fuegos a reunir el conjunto más pequeño de hechos que expliquen los síntomas. El objetivo no es la causa raíz perfecta, sino una causa probable sobre la que puedas actuar sin empeorar el incidente.
Diferentes síntomas apuntan a sospechosos distintos. Páginas lentas suelen indicar consultas a la base de datos lentas, un pico de tráfico o un servicio externo retrasado. Timeouts pueden venir de un proceso bloqueado, un backend saturado o una integración que espera demasiado. Un pico de errores o reintentos normalmente se relaciona con un cambio reciente, una entrada mala o una caída upstream.
Ejecuta un viaje de usuario real de extremo a extremo con una cuenta de prueba normal. Es a menudo la señal más rápida porque toca UI, lógica, base de datos e integraciones.
Concéntrate en unas pocas comprobaciones:
Si estás en AppMaster, esto suele mapearse a un paso de Business Process, un cambio en Data Designer o una configuración de despliegue.
Si las comprobaciones rápidas apuntan a un culpable claro, elige la opción más segura: mantener la mitigación actual o aplicar una corrección mínima permanente. Solo quita límites de tasa, toggles de función o soluciones manuales después de que el viaje tenga éxito dos veces y la tasa de errores se mantenga estable unos minutos.
Son las 10:15 a. m. de un martes. Un equipo despliega un pequeño cambio en un portal de clientes construido en AppMaster. En minutos, los usuarios comienzan a ver páginas en blanco después del login y los pedidos nuevos dejan de entrar.
Soporte recibe tres tickets con el mismo mensaje: “El inicio de sesión funciona, luego el portal no carga.” Al mismo tiempo, la monitorización muestra un pico de errores 500 en la web y una caída en llamadas API exitosas. Lo tratas como un incidente real.
El líder de incidente hace una confirmación rápida: intenta iniciar sesión como usuario de prueba en escritorio y móvil y comprueba la hora del último despliegue. La coincidencia temporal apunta al release, así que asumes que el cambio reciente está involucrado hasta que se demuestre lo contrario.
Los primeros 30 minutos pueden verse así:
A las 10:40 a. m., los errores vuelven a la normalidad. Mantienes la vigilancia mientras soporte confirma que los nuevos tickets disminuyen.
Después, el equipo hace una revisión corta: qué detectó esto primero (alertas vs soporte), qué los ralentizó (falta de dueño, pasos de rollback poco claros) y qué cambiar. Una mejora habitual es añadir una checklist de smoke-test para los tres flujos principales del portal y documentar el rollback como un paso de una sola acción.
La mayoría de incidentes empeoran por una de dos razones: la gente deja que el sistema siga haciendo daño mientras investiga, o cambia demasiadas cosas demasiado rápido. Este runbook busca protegerte de ambas.
Una trampa común es investigar mientras la app aún escribe datos malos. Si un workflow está en bucle, una integración publica duplicados o un bug de permisos permite editar registros indebidamente, pausa primero el proceso ofensivo. En AppMaster, eso puede significar deshabilitar un Business Process, apagar una integración de módulo o restringir temporalmente el acceso para que el problema deje de propagarse.
Otra trampa es “arreglar” por intuición. Cuando varias personas hacen clic y cambian configuraciones, pierdes la línea de tiempo. Incluso pequeños cambios importan durante un incidente. Acordad un único conductor, llevad un registro simple de cambios y evitad apilar ajustes sobre incógnitas.
Errores que suelen alargar las caídas:
La comunicación forma parte de la recuperación. Comparte lo que sabes, lo que no sabes y cuándo llegará la próxima actualización. “Estamos revirtiendo y confirmaremos los eventos de facturación en 15 minutos” es mejor que “Lo estamos investigando.”
No cierres el incidente solo porque los errores pararon. Verifícalo con una checklist corta: las pantallas clave cargan, los nuevos registros se guardan correctamente, las automatizaciones críticas corren una vez y los backlogs (colas, reintentos, jobs programados) están vaciados o pausados de forma segura.
Cuando algo falla, tu mente intentará hacer diez tareas a la vez. Usa esto para mantener la calma, proteger a la gente y recuperar el servicio.
Fija esta sección donde tu equipo realmente la vea.
Toma un minuto para nombrar un propietario del incidente. Una persona decide, todos apoyan.
Estabiliza y contiene (10 minutos): Detén la hemorragia antes de buscar la causa raíz. Desactiva la ruta arriesgada (feature toggle, banner temporal, pausa de colas) y prueba un viaje clave de extremo a extremo. Elige el viaje que más importa al negocio, no el más fácil de probar.
Recupera el servicio (10–20 minutos): Elige la opción más segura: rollback a la última versión conocida buena o aplicar una corrección mínima. En plataformas como AppMaster, eso puede significar redeployar un build anterior o revertir el último cambio, luego confirmar que las tasas de error y tiempos de respuesta vuelven a la normalidad.
Comunica (durante todo): Publica una actualización corta con lo afectado, qué deben hacer los usuarios y la hora de la próxima actualización. Informa a soporte con un guion de dos frases para que todos digan lo mismo.
Cierra limpiamente (antes de que se te olvide): Registra qué pasó, qué cambiaste y la hora de recuperación. Asigna siguientes pasos con responsable y fecha (ajuste de monitorización, brecha de pruebas, limpieza de datos, corrección posterior).
Un incidente no está completamente “resuelto” cuando la app vuelve a funcionar. La forma más rápida de reducir futuras caídas es capturar lo sucedido mientras está fresco y convertir ese aprendizaje en cambios pequeños y reales.
Programa una revisión post-incidente corta dentro de 2–5 días. Manténla sin culpas y práctica. El objetivo no es encontrar a quién culpar, sino facilitar que el próximo incidente sea más fácil de manejar.
Escribe un registro que alguien pueda leer meses después: qué vieron los usuarios, cuándo lo detectaste, qué intentaste, qué funcionó y cuándo volvió el servicio. Incluye la causa raíz si la conoces y anota factores contribuyentes como alertas faltantes, ownership poco claro o pasos de despliegue confusos.
Convierte aprendizajes en tareas con responsables y fechas. Enfócate en los cambios más pequeños que prevengan la misma falla:
Elige una medida de prevención por incidente, aunque sea pequeña. “Cualquier cambio en roles requiere segunda revisión” o “migraciones de datos deben ejecutarse primero en una copia de staging” pueden evitar repeticiones.
Mantén este runbook junto a tu proceso de build y release. Si construyes con AppMaster, anota dónde se despliega cada app (AppMaster Cloud, AWS, Azure, Google Cloud o self-hosted), quién puede redeplegar rápido y quién puede revertir. Si quieres un único lugar para esa documentación, mantenerla junto a las notas del proyecto en appmaster.io facilita encontrarla cuando los minutos cuentan.
¿Cuándo debemos tratar un problema como un incidente para una app sin código?Úsalo siempre que un problema inesperado bloquee tareas clave, haga que la app sea inutilizable por lentitud o ponga en riesgo cambios de datos incorrectos o inseguros. Si los usuarios no pueden iniciar sesión, fallan los pagos, se detienen las automatizaciones o se escriben registros incorrectos, trátalo como un incidente y sigue el runbook.
¿Cuál es la forma más rápida de confirmar que un incidente es real y medir su impacto?Empieza por el impacto al usuario: ¿quién no puede hacer qué ahora mismo y desde cuándo? Reprodúcelo con el mismo rol y dispositivo, y comprueba si afecta a una cuenta, a un segmento o a todos para no perseguir la causa equivocada.
¿Cómo decidimos rápidamente SEV1 vs SEV2 vs SEV3?Declara SEV1 cuando la mayoría de usuarios esté bloqueada o haya riesgo para dinero/seguridad/datos. Usa SEV2 cuando una función clave falla pero existe una solución alternativa, y SEV3 para problemas menores o de alcance limitado; decidir rápido importa más que ser perfecto.
¿Quién debe hacer qué durante un incidente, especialmente en un equipo pequeño?Elige un líder de incidentes que tome las decisiones finales, y asigna un «arreglador», un responsable de comunicaciones y un registrador de notas para que no se pisen ni cambien cosas por error. En equipos pequeños una persona puede cubrir dos roles, pero el rol de líder debe quedar claro.
¿Cómo es la “contención” en AppMaster u otras plataformas sin código?La contención busca detener el daño rápido aunque la causa no esté clara. En AppMaster suele implicar desactivar un Business Process concreto, ocultar temporalmente una acción de la UI que desencadena fallos o pausar una automatización que esté en bucle o escribiendo datos erróneos.
¿Cuándo debemos hacer rollback frente a aplicar una corrección rápida hacia adelante?Haz rollback cuando el problema empezó justo después de un despliegue y tengas una versión conocida como buena que restaure el servicio pronto. Elige una corrección hacia adelante solo si puedes hacer un cambio pequeño y de bajo riesgo y verificarlo rápido sin comprometer más tiempo de actividad.
¿Qué hace que un rollback sea inseguro en apps sin código?Considera el rollback como arriesgado si cambió el esquema de la base de datos, si hubo escrituras irreversibles, o si trabajos en cola y webhooks podrían volver a procesarse con lógica antigua. Si ocurre alguna de estas cosas, estabiliza primero y confirma qué espera la versión anterior antes de redeplegarla.
Si sospechamos corrupción de datos, ¿qué debemos hacer primero?Si se sospecha corrupción de datos, detén primero las escrituras, porque las escrituras erróneas multiplican el trabajo de limpieza. Prácticamente, desactiva formularios, pausa automatizaciones que actualizan registros o bloquea endpoints de actualización hasta confirmar que no se están cambiando nuevos registros erróneamente.
¿Qué debemos decir durante una caída y con qué frecuencia actualizar?Envía actualizaciones cortas y factuales con una cadencia fija indicando qué está afectado, qué estás haciendo y cuándo será la siguiente actualización. Evita especular sobre la causa o culpar a proveedores; usuarios y stakeholders principalmente necesitan claridad y previsibilidad.
¿Cuándo está bien declarar un incidente “resuelto” frente a “en monitoreo”?Considera «resuelto» solo cuando el síntoma principal haya desaparecido y las comprobaciones clave estén limpias (inicio de sesión, flujo principal, tasas de error). Si aplicaste una solución pero aún necesitas vigilar posibles repeticiones, marca como «monitoreo» y explica qué vas a vigilar y durante cuánto tiempo.
21 ene 2026
8 min
20 ene 20268 min
20 ene 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
