Monitoreo de actividad, rendimiento y errores
Zinn Digital® supervisa las direcciones web que nos proporciona (tiempo de actividad, Core Web Vitals y uso de recursos en comparación con su plan) y las muestra por sitio en el panel de control. Las alertas se envían por correo electrónico, Telegram, Slack o a su propio webhook, y nuestra página de estado se encuentra fuera de la plataforma para que siga respondiendo incluso cuando nosotros no podamos hacerlo. La supervisión del tiempo de actividad y de la velocidad de las páginas ya está activa: añada cualquier dirección web (tres gratuitas en cada cuenta, y no es necesario que la alojemos nosotros) y la comprobaremos cada minuto desde fuera de nuestra propia red. Disponibilidad: el seguimiento de errores por sitio y las estadísticas de recursos por sitio están en desarrollo activo y todavía no están disponibles. Todo lo demás descrito aquí está activo hoy mismo.
Los paneles de control de alojamiento suelen decirte por lo que estás pagando. El nuestro te dice lo que está haciendo tu sitio. Cada sitio que ejecutas con nosotros informa el mismo conjunto de señales, por sitio, sin ningún agente que instalar ni nada que configurar.
Comprobaciones continuas de disponibilidad por sitio, contrastadas con el propio historial del sitio para que un fallo leve y una caída real se diferencien. El estado de disponibilidad es una señal prioritaria en la que la plataforma actúa, no un gráfico que nadie lee.
Datos de rendimiento reales por sitio: las métricas en las que Google realmente se basa para posicionar. Las páginas lentas aparecen como una medida sobre la que puedes actuar, junto con los controles de caché que las solucionan.
Los registros de errores HTTP y PHP están disponibles por sitio, por lo que un error fatal debido a una mala actualización de un plugin o a un despliegue fallido es algo que puedes ir a buscar en lugar de tener que adivinarlo.
Ancho de banda por sitio, además del uso de recursos medido según los derechos de su plan, incluidas las estadísticas LVE por sitio, para que pueda ver qué sitio está trabajando más y si se encuentra cerca de su límite.
Un panel que tienes que recordar abrir no es monitorización. Cada señal alimenta la capa de notificaciones de la plataforma y tú eliges dónde se recibe.
Una página de estado alojada en la infraestructura que supervisa no sirve de nada justo en el momento en que la necesitas. La nuestra está deliberadamente en otra parte.
Nuestra página de estado pública está alojada de forma independiente en una infraestructura separada, totalmente fuera de la plataforma: en una máquina diferente y con un dominio de fallo distinto al del plano de control y al de la flota sobre la que informa. Cuando algo va mal en la plataforma, la página de estado sigue respondiendo, porque nada de lo que depende se encuentra dentro del incidente.
Está personalizada, se alimenta de la misma monitorización que activa sus alertas por sitio y es independiente por diseño en lugar de por accidente. El frontend público sigue el mismo principio: el sitio de marketing y el centro de ayuda se despliegan por separado del clúster del plano de control, por lo que un incidente en la plataforma no derriba nuestra documentación al mismo tiempo.
Esta es la misma lógica que impregna el resto de la plataforma: dominios de fallo separados, ausencia de destino compartido y nada que pueda tumbar tanto el recurso como la herramienta que usas para diagnosticarlo.
Las señales valen más cuando alguien puede actuar sobre ellas. Las nuestras están conectadas al asistente y al servidor MCP, no encerradas en un gráfico.
Cuando empiezas a enviar un ticket, el asistente ejecuta primero un diagnóstico en tiempo real del sitio afectado —tiempo de actividad, errores HTTP y PHP, estado de SSL y DNS, límites de recursos y fallos de LVE, alertas de malware, conflictos de plugins, estado de la base de datos y caché— antes de que intervenga una persona.
Dentro de tus permisos y de los límites de la plataforma, limpiará la caché, reiniciará los trabajadores de PHP, reparará o renovará el SSL, reparará las tablas de la base de datos, deshabilitará un plugin con errores fatales o purgará la CDN; luego volverá a comprobar la señal y confirmará si realmente se ha resuelto.
Si aún se necesita a un humano, el ticket llega prellenado con los diagnósticos, lo que se intentó y lo que ocurrió, de modo que el soporte comienza a partir de los hechos en lugar de pedirle que describa el síntoma.
Conecta cualquier herramienta de IA compatible con MCP para que pueda leer la salud del sitio, los registros recientes, las métricas, el tiempo de actividad y los errores como recursos; así tu propio agente podrá diagnosticar antes de actuar, bajo OAuth 2.1 con tokens revocables con ámbito de organización y rol, y un registro de auditoría completo.
El monitoreo de rendimiento pertenece junto a las herramientas que cambian el rendimiento. En nuestra plataforma, se ubica entre la pila de caché y la capa de SEO.
Detrás de tu panel se encuentra la misma pila de observabilidad sobre la que ejecutamos la plataforma: Prometheus y Grafana para métricas, OpenTelemetry para trazabilidad distribuida en todo el motor, los flujos de trabajo y los controladores, y registros estructurados centralizados etiquetados por inquilino con datos de auditoría mantenidos por separado.
Las métricas se recopilan por servicio, por trabajador y por inquilino, con estadísticas de LVE por sitio desde la capa de aislamiento. Cada ejecución de flujo de trabajo (aprovisionamiento, migración, aplicación) es visible de extremo a extremo, razón por la cual una respuesta de soporte puede ser específica en lugar de una suposición.
La monitorización a escala es un problema de volumen de datos, por lo que está diseñada como tal. Las métricas de alto volumen se particionan por tiempo y se consolidan en lugar de conservarse por sitio y por minuto para siempre, los trazos se muestrean y los controles de cardinalidad por inquilino evitan que una cuenta ruidosa degrade los paneles de los demás. El objetivo de diseño es un millón de sitios, no la cantidad que gestionamos hoy.
Las alertas se enrutan a través de Alertmanager hacia nuestro turno de guardia con SLOs definidos y rastreados, manteniéndose deliberadamente separadas de las notificaciones al cliente mencionadas antes, para que el ruido operativo nunca llegue a tu bandeja de entrada y tus alertas nunca se queden en cola detrás de las nuestras.
Por sitio web: disponibilidad, Core Web Vitals y rendimiento, ancho de banda y uso de recursos medidos en función de lo que incluye tu plan, incluidas las estadísticas de LVE por sitio web de la capa de aislamiento. Todo se muestra en el panel de control para cada sitio web, sin necesidad de instalar ningún agente.
A través de los canales que elijas para conectarte: correo electrónico, Telegram, Slack o tu propio endpoint de webhook. Las preferencias de notificación se configuran por organización y por usuario, por lo que tú decides qué eventos llegan a cada canal y a qué persona. Las entregas de webhooks están firmadas con HMAC, se reintentan con retroceso exponencial y se registran, para que puedas inspeccionar o repetir cualquier envío.
Eso es exactamente lo que está diseñado para evitar. La página de estado se aloja de forma independiente en otra infraestructura, totalmente fuera de la plataforma y en un dominio de fallo diferente al del plano de control y la flota sobre la que informa, porque una página de estado que se ejecuta en la misma infraestructura que supervisa no sirve para nada durante una interrupción.
Es el objetivo de disponibilidad para el que diseñamos y operamos, y se indica como una garantía en los planes Footprint-Free. Es un compromiso sobre cómo se diseña la plataforma (computación aislada por sitio, servicios sin estado escalables horizontalmente, dominios de fallo separados) en lugar de una medición publicada de disponibilidad pasada. Nuestro compromiso contractual es algo separado y más limitado, y está publicado: consulte el SLA de disponibilidad en /legal/sla, que establece el nivel que garantizamos y los créditos de servicio que pagamos cuando no lo cumplimos.
Sí. La salud del sitio, los registros recientes, las métricas, el tiempo de actividad y los datos de errores se exponen como recursos a través de nuestro servidor MCP alojado, por lo que cualquier herramienta de IA compatible con MCP —como Claude, Cursor, ChatGPT y otras— puede leerlos y diagnosticarlos antes de actuar. El acceso se realiza mediante OAuth 2.1, con alcance limitado a su organización y al rol del usuario conectado, revocable por herramienta, y cada acción queda registrada en la auditoría. Los webhooks de los clientes cubren el mismo terreno para las integraciones convencionales.
Las señales de observabilidad descritas aquí forman parte de la plataforma y se muestran en su panel de control para los sitios que aloja con nosotros, y el módulo gratuito de SEO Basics —indexados, Trust Flow, Core Web Vitals de la página principal— se incluye en todos los planes. El monitoreo de SEO más profundo, como el seguimiento de posiciones y el monitoreo de backlinks, se vende como complementos de pago independientes, y la optimización de velocidad asistida es un extra adquirible.
Sí. La prueba de Footprint-Free dura 14 días, no requiere tarjeta y cubre hasta 5 sitios; sin datos de pago ni compromiso. Despliega unos cuantos sitios y observa lo que el panel de control realmente reporta antes de decidir.
Inicia una prueba de 14 días sin tarjeta y consulta el tiempo de actividad, Core Web Vitals, los errores y el uso de recursos por sitio desde el primer despliegue, con alertas donde las necesites. Migraciones gratuitas y una garantía de devolución de dinero de 30 días que respalda todo.
Empieza gratis