Monitoriza algo más que la página de inicio. Una configuración completa cubre la página de inicio, cada ruta de conversión (inicio de sesión, registro, checkout y búsqueda), los endpoints de API de los que dependen tus aplicaciones, los callbacks de pago y los webhooks, las tareas programadas, los certificados SSL, el registro del dominio, los registros DNS (incluido MX), los servidores que hay debajo y los servicios de terceros de los que dependes. A la web de una pequeña empresa le bastan unos pocos checks; una tienda o un producto SaaS necesita unas cuantas decenas. Empieza por lo que genera ingresos y después añade lo que puede caducar o fallar sin avisar. Para ver el panorama general, lee cómo una monitorización de uptime fiable ayuda a que tu web rinda.
Esta checklist repasa cada punto, explica qué comprobar y por qué, y termina con configuraciones de ejemplo para una web pequeña, una tienda online, un producto SaaS y una agencia, además de una convención de nombres que lo mantiene todo legible.
1. La página de inicio
La página de inicio es el primer monitor evidente, y uno bueno: si está caída, está caído todo. Pero a menudo se sirve desde una CDN o una caché de páginas, así que puede seguir en pie mientras la aplicación que hay detrás falla. Monitorízala con un check HTTP(S) cada minuto y valida un contenido estable, como el nombre de la empresa en el pie de página, para que una página de error en caché no cuente como disponible. Después pasa a las páginas que te dicen más.
2. Rutas de conversión
Son las páginas que generan ingresos o retienen clientes, y dependen de la base de datos, las sesiones y el código de la aplicación que la página de inicio quizá no toca:
Inicio de sesión: demuestra que las sesiones y la base de datos de usuarios funcionan. Monitoriza la página de login y valida que el formulario aparece.
Alta o registro: el punto de partida de cada cliente nuevo.
Carrito y checkout: en una tienda, las páginas más importantes del sitio. Monitoriza la propia página de checkout, no solo las fichas de producto.
Búsqueda: suele depender de un servicio aparte, así que falla por su cuenta. Monitoriza una URL de resultados con una consulta que siempre devuelva resultados y valida que aparece alguno.
Formularios de reserva o de contacto, si es así como te llegan los leads.
Compruébalas cada minuto. Para la mayoría de los negocios, un checkout roto cuesta más por minuto que cualquier otra cosa de esta lista. La monitorización de uptime de Uptimecheck admite métodos y cabeceras personalizados y valida el código de estado, palabras clave y JSON en cada página. Para comprobar que el login o el checkout funcionan de verdad, y no solo que cargan, un monitor de flujos los recorre paso a paso, opcionalmente en un navegador real, pasando valores de un paso a otro y con los secretos protegidos.
3. Endpoints de API
Si tienes una app móvil, un frontend de una sola página o integraciones con partners, la API es el producto. Monitoriza:
Un endpoint de salud que compruebe la base de datos, la caché y el disco. Consulta cómo crear un endpoint de health check.
El endpoint principal de lectura, con la cabecera de clave de API que envían tus clientes.
Un endpoint de escritura, con un payload de prueba seguro, si las escrituras son críticas.
Valida el cuerpo de la respuesta, no solo el código de estado: una API que devuelve 200 con un mensaje de error sigue caída. La monitorización de API y la checklist de monitorización de API profundizan más.
4. Callbacks de pago y webhooks
Las pasarelas de pago, los servicios de envío y otras plataformas llaman de vuelta a tu web para confirmar pedidos y actualizar estados. Si el endpoint que los recibe se rompe, los pagos pueden completarse mientras los pedidos nunca se marcan como pagados. Nadie ve una página de error, porque no hay ningún visitante de por medio.
Normalmente no puedes enviar un callback real desde un monitor, pero sí puedes comprobar que el endpoint responde. Muchos receptores de webhooks devuelven un código 4xx ante una petición sin una firma válida; si esa es la respuesta esperada, monitoriza que llegue. Entonces, un 5xx o un timeout significa que el propio receptor está roto. Combínalo con los registros de entrega del proveedor, que muestran los callbacks fallidos desde su lado.
5. Cron jobs y procesos en segundo plano
Las copias de seguridad, las importaciones, la facturación periódica, las exportaciones de feeds, los envíos de newsletter y los workers de colas no tienen una URL que comprobar. Fallan en silencio. Dale a cada uno un heartbeat: la tarea llama a una URL única al terminar y se envía una alerta cuando esa llamada no llega a tiempo. Los planes de Uptimecheck cuentan los heartbeats aparte de los monitores, así que no restan de tus checks de la web.
6. Certificados SSL
Un certificado caducado muestra a cada visitante un aviso del navegador a pantalla completa y deja directamente sin servicio a los clientes de la API. Monitoriza el certificado de cada hostname que sirves, incluidos www, el subdominio de la API, el dominio de la página de estado y los paneles de administración, y recibe recordatorios semanas antes de que caduque. La renovación automática hace que las caducidades sean menos frecuentes, no imposibles. Consulta la monitorización de la caducidad de certificados SSL para conocer los fallos más habituales.
7. Registro del dominio
Cuando caduca el registro de un dominio, la web, el correo y la API que dependen de él se paran a la vez. Los recordatorios del registrador suelen ir a una dirección antigua. Controla la fecha de caducidad de cada dominio que tengas, incluidas las variantes por país, los dominios de campañas y los nombres de marca antiguos que todavía redirigen.
8. Registros DNS, incluido MX
El DNS decide adónde van el tráfico y el correo. Vigila los cambios en:
A y AAAA: desde dónde se carga la web.
NS: quién controla la zona. Un cambio aquí siempre merece una revisión.
MX: quién recibe tu correo, incluidas las confirmaciones de pedido y los restablecimientos de contraseña.
TXT: SPF, DKIM y DMARC. Un registro eliminado puede mandar tu correo directamente a spam. El monitor de dominios de Uptimecheck también comprueba SPF, DKIM y DMARC dos veces al día y te dice cómo solucionar cada problema, con un registro DNS listo para pegar cuando eso lo arregla; consulta la monitorización de la autenticación del correo.
CNAME y CAA: los alias de la CDN y qué autoridades de certificación pueden emitir certificados para el dominio.
Un cambio inesperado es o un error o un ataque. La monitorización de DNS te avisa con el valor antiguo y el nuevo. Si tienes tu propio servidor de correo, añade también un check de puerto, por ejemplo SMTP en el puerto 465.
9. Servidores
Si gestionas tus propios servidores o VPS, monitoriza la CPU, la memoria, el disco, la red y los reinicios. Así detectas las causas de las caídas antes de que se conviertan en síntomas: un disco que se llenará el jueves, una fuga de memoria, un reinicio tras el que un servicio no arrancó. La monitorización de servidores está junto a tus checks de uptime, así que la causa y el síntoma aparecen en la misma pantalla. Con un hosting totalmente gestionado, a menudo puedes saltarte este punto y confiar en el proveedor.
10. Dependencias de terceros
Tu web depende de servicios que no gestionas tú: pasarelas de pago, envío de correo, búsqueda, un CMS headless, un proveedor de autenticación, una CDN. Cuando uno falla, tu web puede cargar mientras la función que depende de él está rota. Monitoriza los endpoints públicos de los que dependes, o tus propios endpoints que los usan, para poder decirle a un cliente en minutos si el problema es tuyo o del proveedor. Mándalos a un canal de alertas de menor prioridad, porque no puedes arreglarlos tú.
La monitorización de terceros de Uptimecheck sigue las páginas de estado de 31 servicios como Klarna, Swish, Shopify, Cloudflare y OpenAI, o cualquier página alojada en Statuspage, para que sus incidencias aparezcan junto a tus propios monitores.
11. Salud del sitio
Algunos problemas nunca tiran una página: un enlace roto tras una migración, una imagen cargada por HTTP sin cifrar, una página que se volvió más lenta tras instalar un plugin nuevo. Un análisis diario los detecta. El monitor de salud del sitio de Uptimecheck rastrea tu web y su sitemap cada día en busca de enlaces rotos y contenido mixto, y mide la velocidad de carga y las Core Web Vitals con Google Lighthouse en móvil y escritorio.
¿Cuántos monitores necesitas?
Las configuraciones siguientes son ejemplos para adaptar, no recetas cerradas:
Tipo de sitioConfiguración de ejemploWeb de una pequeña empresa, como fjordstudio.sePágina de inicio, página del formulario de contacto, SSL, dominio, DNS para A y MX, un heartbeat para la copia de seguridad. Unos 3 monitores HTTP más los checks de caducidad y DNS.Tienda online, como northwind.shopPágina de inicio, una página de categoría, una ficha de producto, carrito, checkout, login, búsqueda, callback de pago, endpoint de salud, SSL en cada hostname, dominio, DNS, heartbeats para las copias de seguridad, las exportaciones de feeds y la sincronización de pedidos, y los servidores. Aproximadamente de 10 a 15 monitores HTTP.Producto SaaS, como lumenanalytics.ioWeb de marketing, login de la app, registro, salud de la API, endpoints principales de la API, receptor de webhooks, página de estado, SSL, dominios, DNS, heartbeats para cada worker y tarea programada, y servidores. A menudo de 15 a 40 monitores.AgenciaEl conjunto de la web pequeña para cada cliente, más checkout y login en las tiendas de los clientes, agrupados por cliente. Normalmente unos pocos monitores por cliente, multiplicados por el número de clientes.
Empieza por las rutas de conversión y los checks de caducidad, déjalo funcionar dos semanas y después añade lo que echaste de menos durante la primera incidencia.
Convenciones de nombres
El nombre de un monitor es lo primero que alguien lee en una alerta de madrugada. Haz que responda a «qué se ha roto, dónde y cuánto de grave es» sin tener que abrir nada:
[client or product] – [environment] – [what] – [check type]
Northwind – prod – Checkout – HTTPS
Northwind – prod – Payment callback – HTTPS
Northwind – prod – Nightly backup – heartbeat
Lumen – prod – API health – HTTPS
Lumen – staging – API health – HTTPS
Fjord Studio – prod – MX record – DNS
Usa el mismo orden en todas partes, para que las alertas se puedan revisar de un vistazo y ordenar.
Llama a las cosas como las llama el equipo, no por los hostnames internos.
Marca los entornos con claridad, para que una alerta de staging nunca parezca de producción.
En las agencias, empieza por el nombre del cliente y agrupa los monitores por cliente en proyectos, para que los monitores y las alertas de cada cliente estén juntos.
La checklist
Página de inicio, con validación de contenido.
Inicio de sesión, registro, checkout y búsqueda.
Salud de la API y endpoints principales.
Callbacks de pago y receptores de webhooks.
Un heartbeat para cada tarea programada que importe.
SSL en cada hostname y el registro de cada dominio.
Registros DNS: como mínimo A, AAAA, NS, MX y TXT.
Servidores, si gestionas los tuyos propios.
Los servicios de terceros clave, en un canal de menor prioridad.
Salud del sitio: enlaces rotos, contenido mixto y velocidad de carga, analizados a diario.
Nombres claros y alertas dirigidas al responsable de cada elemento.
Uptimecheck cubre webs, API, flujos de varios pasos, heartbeats, SSL, dominios, DNS, servidores, servicios de terceros y salud del sitio en una sola cuenta. Empieza una prueba gratuita de 14 días, sin tarjeta de crédito.