Cómo saber si tu aplicación falla antes de que te avise un cliente
Para enterarte de que tu aplicación falla antes que tus clientes necesitas tres cosas: una comprobación automática que la visite cada pocos minutos desde fuera, alertas que lleguen a una persona concreta con un teléfono delante, y una métrica de negocio vigilada (los pedidos por hora, los registros, los pagos completados). Con esas tres piezas, la mayoría de las caídas se detectan en minutos en lugar de en la llamada enfadada de un cliente al día siguiente.
Lo cuento como se monta en la práctica, por orden de lo que más detecta con menos esfuerzo, y con lo que debes exigir a quien te mantiene la aplicación.
Por qué no basta con que «la web se vea»
El error de partida es pensar que una aplicación está bien o está caída. En realidad falla por partes, y las averías más caras son las que no se ven al abrir la página de inicio.
Los casos típicos: la web carga perfecta pero el formulario de contacto no envía nada porque caducó la contraseña del correo saliente; el catálogo funciona pero la pasarela de pago rechaza todo; la aplicación responde pero tarda doce segundos y los usuarios se van; la copia de seguridad lleva tres semanas sin ejecutarse y nadie lo sabe. En todos, abrir la página no detecta nada.
Por eso monitorizar no es mirar si responde: es comprobar que los caminos que te dan dinero siguen funcionando de principio a fin.
Los cuatro niveles que hay que vigilar
Ordénalo así y te quedará claro qué te falta.
- Disponibilidad: ¿responde el servidor? Es el nivel más básico y el único que tiene mucha gente.
- Funcionalidad: ¿se puede entrar, buscar, añadir al carrito y pagar? Esto se comprueba simulando esos pasos, no mirando el servidor.
- Rendimiento: ¿cuánto tarda cada página y cada llamada importante? Una aplicación lenta pierde clientes sin dar ningún aviso.
- Negocio: ¿cuántos pedidos, altas o presupuestos llevas esta hora comparado con lo normal? Es el nivel que detecta los fallos que ninguna máquina reconoce como error.
Ese cuarto nivel es el más valioso y el que casi nadie monta. Un ejemplo real de cómo falla una tienda sin que salte ninguna alarma técnica: un cambio en el formulario de pago deja de validar un campo en un navegador concreto. El servidor está sano, los tiempos son buenos, no hay errores en los registros... y las ventas de ese navegador son cero. Solo una alerta sobre el número de pedidos lo pilla el mismo día.
Comprobación desde fuera: la pieza que más rinde
Si solo vas a montar una cosa, monta esta. Un servicio externo que visita tu aplicación cada uno o cinco minutos desde varios lugares y avisa si no responde o si responde mal.
Cuatro detalles que marcan la diferencia entre un aviso útil y un aviso que se ignora:
- Comprueba contenido, no solo el código de respuesta. Una página de error puede devolver un código correcto. Haz que el control busque un texto que solo aparece cuando todo va bien.
- Vigila los caminos completos, no la portada: identificación de usuario, búsqueda, añadir al carrito, inicio del pago. Son los que importan.
- Mide desde varios países si vendes fuera, y confirma el fallo desde dos puntos antes de avisar, para no despertar a nadie por un corte de red local.
- Vigila los certificados y el dominio. La caída más tonta y más frecuente es un certificado caducado o un dominio sin renovar. Un aviso treinta días antes lo evita para siempre.
Añade las tareas de fondo. Si tu aplicación envía facturas de noche, sincroniza stock o hace copias, haz que cada proceso avise al terminar bien; si el aviso no llega a su hora, salta la alerta. Es la única forma de detectar lo que falla por no ejecutarse.
Errores, registros y trazas: para saber qué ha pasado
La monitorización te dice que algo va mal. Los registros te dicen qué. Sin ellos, cada incidencia empieza con media hora de adivinanzas.
Lo mínimo razonable: un recolector de errores de la aplicación que agrupe los fallos repetidos, con el detalle técnico, el usuario afectado y los pasos previos; registros centralizados y buscables de todos los servidores, no repartidos en ficheros a los que hay que entrar por separado; y conservación suficiente para investigar algo que pasó la semana pasada.
Vigila también los errores del lado del navegador, no solo los del servidor. Buena parte de los fallos que arruinan una venta ocurren en el móvil del cliente y nunca llegan a tu servidor.
Y define un umbral de ruido. Si tu sistema de errores escupe cuatrocientos avisos al día, nadie los lee y vuelves al punto de partida. Agrupa, silencia lo conocido y revisa lo nuevo.
Alertas que alguien atiende de verdad
Una alerta que llega a una dirección de correo compartida que nadie abre es lo mismo que no tener alertas. Esta parte es organizativa más que técnica, y es donde fallan la mayoría de las empresas pequeñas.
Decide y escribe cuatro cosas: qué avisos son urgentes y qué avisos pueden esperar al día siguiente; por qué canal llega cada tipo (el urgente, por llamada o mensaje al móvil, nunca solo por correo); quién responde en cada franja y quién es el segundo si el primero no contesta; y qué se hace en los primeros diez minutos.
Para una pyme no hace falta un equipo de guardia. Basta con que una persona tenga el móvil con los avisos urgentes activados y una lista corta de primeros pasos: comprobar si es general o solo tuyo, mirar el panel, avisar al proveedor con el enlace del aviso. La diferencia entre quince minutos y ocho horas de caída suele estar ahí, no en la herramienta.
Qué exigir a quien mantiene tu aplicación
Si tu aplicación la lleva un proveedor, la monitorización es parte del servicio y debería estar en el contrato. Pregunta esto, en estas palabras:
¿Qué estáis vigilando exactamente y cada cuánto? ¿A quién llega la alerta y en qué horario? ¿En cuánto tiempo os comprometéis a responder y a resolver, según la gravedad? ¿Tengo acceso al panel para verlo yo? ¿Me enviáis un informe mensual con las caídas y los tiempos? ¿Las ventanas de mantenimiento están pactadas y avisadas?
Las respuestas van en un acuerdo de nivel de servicio. Y pide acceso de lectura al panel aunque no vayas a mirarlo todos los días: el mes que algo vaya mal, querrás ver los datos tú mismo y no un resumen.
Un último punto que se olvida: que las alertas apunten también a ti, no solo al proveedor. Es tu negocio el que se para.
Por dónde empezar esta semana
Un orden realista, de mayor a menor retorno por el esfuerzo que cuesta: primero, comprobación externa cada cinco minutos de la portada y de dos caminos críticos, con aviso al móvil y control de certificados. Segundo, recolector de errores de la aplicación. Tercero, avisos de las tareas de fondo que hoy no se vigilan. Cuarto, una alerta sobre tu métrica de negocio: pedidos, altas o formularios por hora. Quinto, registros centralizados y un informe mensual.
Los dos primeros se montan en una tarde y detectan la mayoría de lo que hoy te enteras por un cliente. Los siguientes van cuando toque.
En resumen: vigila desde fuera, comprueba caminos y no solo servidores, haz que las alertas lleguen a un móvil con nombre y apellidos y añade una métrica de negocio, que es la que detecta lo que ninguna máquina considera un error. Si quieres que revisemos qué se está vigilando hoy en tu aplicación y qué agujeros tiene, escríbenos y lo miramos contigo.
Artículos relacionados
Preguntas frecuentes sobre
Cómo mejorar mi negocio con la metodología Anticompetencia
En Tangram no queremos que la información pase por una cadena interminable de intermediarios donde se pierden los detalles importantes.
Contarás con un interlocutor que coordinará la comunicación y trasladará las decisiones al equipo responsable de tu proyecto.
Cuando sea necesario profundizar en cuestiones de estrategia, diseño o tecnología, podremos involucrar a los especialistas correspondientes.
Así tendrás una comunicación organizada, sin necesidad de gestionar personalmente a todos los profesionales que intervienen.
Queremos que tengas acceso al conocimiento de un equipo especializado, sin sufrir la complejidad de coordinarlo.
No tendrás que averiguar a quién escribir cada vez que tengas una duda.
En Tangram contemplamos la figura del Account Manager como interlocutor principal, encargado de acompañarte durante el proyecto, coordinar la comunicación y facilitar el seguimiento de las decisiones.
Nuestra metodología incluye reuniones de revisión, canales de comunicación y herramientas para que puedas participar en el trabajo.
La organización concreta, la frecuencia de las reuniones y los canales disponibles se establecerán según el proyecto contratado.
Lo importante es que sepas con quién hablar, en qué punto está tu proyecto y qué decisiones necesitan tu participación.
Sí, podemos valorar una colaboración con los profesionales que ya trabajan en tu empresa.
No siempre tiene sentido sustituir un equipo que conoce bien tu negocio. En muchas situaciones, lo más útil es complementar sus conocimientos con especialistas en determinadas áreas.
Podemos estudiar qué responsabilidades asumiría Tangram, cuáles mantendría tu equipo y cómo coordinar las decisiones para evitar duplicidades.
La forma concreta de colaboración dependerá de la organización, las herramientas y las necesidades del proyecto.
No se trata de reemplazar lo que ya funciona, sino de aportar el conocimiento que necesitas para llegar más lejos.
No tienes por qué cambiar de proveedor para explorar una colaboración con Tangram.
Durante nuestra trayectoria hemos trabajado con agencias y consultoras, participando en proyectos en los que cada empresa asumía una parte diferente del trabajo.
Esa experiencia nos permite comprender la importancia de definir responsabilidades y coordinar a los profesionales implicados.
Podemos valorar una colaboración para cubrir necesidades concretas que tu proveedor actual no ofrece o para reforzar determinadas áreas.
Si tienes una relación profesional que funciona, no queremos que la rompas sin motivo. Queremos encontrar dónde podemos aportar valor.
La confidencialidad es especialmente importante cuando hablamos de nuevas ideas de negocio, información económica, estrategias comerciales o desarrollos tecnológicos.
En Tangram tenemos experiencia trabajando en proyectos sujetos a acuerdos de confidencialidad, motivo por el que no podemos mostrar públicamente muchos de los trabajos en los que hemos participado.
Si tu proyecto requiere un acuerdo de confidencialidad (NDA) antes de compartir información sensible, podemos revisar sus condiciones y acordar cómo proteger esa información antes de entrar en los detalles.
Entendemos que la confianza empieza por respetar lo que todavía no quieres hacer público.