Monitoreo de tiempo de actividad, rendimiento y errores
Zinn Digital® supervisa las direcciones web que usted nos proporciona —tiempo de actividad, Core Web Vitals y uso de recursos frente a su asignación— y lo muestra por sitio en el panel de control. Las alertas se envían al correo electrónico, Telegram, Slack o a su propio webhook, y nuestra página de estado se aloja fuera de la plataforma para que siga respondiendo cuando nosotros no podamos hacerlo. La monitorización del tiempo de actividad y de la velocidad de página ya está disponible: 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 aún no se encuentran disponibles. Todo lo demás descrito aquí ya está disponible hoy.
Los paneles de control de alojamiento suelen indicarle por qué está pagando. El nuestro le indica qué está haciendo su sitio. Cada sitio que aloja con nosotros reporta el mismo conjunto de señales, por sitio, sin necesidad de instalar ningún agente ni configurar conexiones.
Comprobaciones continuas de disponibilidad para cada sitio, contextualizadas con su propio historial para distinguir una anomalía momentánea de una interrupción real. El estado de actividad es una señal prioritaria sobre la que actúa la plataforma, no un gráfico que nadie consulta.
Datos de rendimiento reales por sitio: las métricas con las que Google realmente clasifica. Las páginas lentas aparecen como una métrica sobre la que puede actuar, junto a los controles de almacenamiento en caché que las corrigen.
Los registros de errores de HTTP y PHP están disponibles por cada sitio, de modo que un error fatal provocado por una actualización defectuosa de un complemento o una implementación fallida es algo que puede localizar en lugar de adivinar.
Ancho de banda por sitio, más el uso de recursos medido respecto a los límites de su plan —incluidas las estadísticas de LVE por sitio—, para que pueda ver qué sitio trabaja más intensamente y si está cerca del límite.
Un panel de control que tiene que recordar abrir no es supervisión. Cada señal alimenta la capa de notificaciones de la plataforma y usted elige dónde llega.
Una página de estado alojada en la misma infraestructura que supervisa resulta inútil justo en el momento en que usted la necesita. La nuestra está deliberadamente en otro lugar.
Nuestra página pública de estado está alojada de forma independiente en una infraestructura separada, completamente fuera de la plataforma: una máquina diferente y un dominio de fallos distinto del plano de control y de la flota sobre la que informa. Cuando ocurre un problema con la plataforma, la página de estado sigue respondiendo, ya que nada de lo que depende se encuentra afectado por la incidencia.
Lleva su marca, se alimenta del mismo monitoreo que genera sus alertas por sitio y es independiente por diseño y no por casualidad. La interfaz pública sigue el mismo principio: el sitio de marketing y el centro de ayuda se implementan por separado del clúster del plano de control, de modo que un incidente en la plataforma no derribe nuestra documentación.
Esta es la misma lógica que rige en el resto de la plataforma: dominios de fallo separados, sin destino compartido y nada que pueda inhabilitar tanto el elemento como la herramienta que usted utiliza para diagnosticarlo.
Las señales tienen más valor cuando algo puede actuar sobre ellas. Las nuestras están conectadas al asistente y al servidor MCP, no encerradas en un grafo.
Cuando comienza a crear un ticket, el asistente realiza primero un diagnóstico en vivo en el sitio afectado (tiempo de actividad, errores de 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 sus permisos y de las medidas de seguridad de la plataforma, borrará la caché, reiniciará los procesos de trabajo de PHP, reparará o renovará el SSL, reparará las tablas de la base de datos, desactivará un plugin que cause un error fatal o purgará la CDN; luego volverá a comprobar la señal y confirmará si realmente se resolvió.
Si aún se necesita la intervención de una persona, el ticket llega precumplimentado con el diagnóstico, lo que se ha intentado y lo que ha ocurrido, de modo que el equipo de asistencia técnica parte de los hechos en lugar de pedirle que describa el síntoma.
Conecte cualquier herramienta de IA compatible con MCP y podrá leer el estado del sitio, los registros recientes, las métricas, el tiempo de actividad y los errores como recursos, para que su propio agente pueda diagnosticar antes de actuar, bajo OAuth 2.1 con tokens revocables y delimitados por organización y rol, además de un registro de auditoría completo.
La monitorización del rendimiento debe estar junto a las herramientas que lo modifican. En nuestra plataforma, se sitúa entre la infraestructura de caché y la capa de SEO.
Detrás de su panel de control se encuentra la misma pila de observabilidad sobre la que ejecutamos la plataforma: Prometheus y Grafana para métricas, OpenTelemetry para rastreo distribuido en el motor, flujos de trabajo y controladores, y registros estructurados centralizados con etiquetas de inquilino y datos de auditoría separados.
Las métricas se recopilan por servicio, por proceso de trabajo (worker) y por inquilino, con estadísticas LVE por sitio desde la capa de aislamiento. Cada ejecución de flujo de trabajo — aprovisionamiento, migración, cumplimiento — es visible de principio a fin, razón por la cual una respuesta de soporte técnico puede ser específica en lugar de una suposición.
La monitorización a gran escala es un problema de volumen de datos, por lo que se diseña como tal. Las métricas de gran volumen se dividen temporalmente y se consolidan en lugar de conservarse por sitio y por minuto para siempre, las trazas se muestrean y los controles de cardinalidad por cliente evitan que una cuenta ruidosa degrade los paneles de control de los demás. El objetivo del diseño es de un millón de sitios, no la cifra que gestionamos hoy.
Las alertas se dirigen a través de Alertmanager a nuestra rotación de guardia con SLO definidos y monitorizados — deliberadamente separados de las notificaciones a clientes anteriores, de modo que el ruido operativo nunca llegue a su bandeja de entrada y sus alertas nunca hagan cola detrás de las nuestras.
Por sitio: tiempo de actividad, Core Web Vitals y rendimiento, ancho de banda y uso de recursos medido en función de los derechos de su plan, incluidas las estadísticas de LVE por sitio de la capa de aislamiento. Todo se muestra en el panel de control por sitio, sin necesidad de instalar ningún agente.
A través de cualquiera de los canales que conecte: correo electrónico, Telegram, Slack o su propio extremo de webhook. Las preferencias de notificación se configuran por organización y por usuario, por lo que usted decide qué eventos llegan a qué canal y a qué persona. Las entregas de webhooks están firmadas con HMAC, se reintentan con retroceso y se registran, para que pueda inspeccionar o reproducir cualquier entrega.
Eso es exactamente lo que está diseñado para evitar. La página de estado se aloja de forma independiente en una infraestructura separada, totalmente fuera de la plataforma, en un dominio de fallos 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 de nada durante una interrupción.
Es el objetivo de tiempo de actividad (uptime) en función del cual construimos y operamos, y se establece como una garantía en los planes Footprint-Free. Se trata de un compromiso sobre la ingeniería de la plataforma — cómputo aislado por sitio, servicios sin estado escalables horizontalmente, dominios de fallo independientes — y no de una medición publicada de la disponibilidad pasada. Nuestro compromiso contractual es independiente y más acotado, y está publicado: consulte el Uptime SLA en /legal/sla, donde se detalla el nivel que garantizamos y los créditos de servicio que abonamos en caso de incumplimiento.
Sí. El estado 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, de modo que cualquier herramienta de IA compatible con MCP (Claude, Cursor, ChatGPT y otras) puede leerlos y diagnosticarlos antes de actuar. El acceso es mediante OAuth 2.1, delimitado a su organización y al rol del usuario que se conecta, revocable por herramienta, y cada acción se registra en una auditoría. Los webhooks de cliente cubren el mismo ámbito 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 SEO Basics —indexado, Trust Flow, Core Web Vitals de la página de inicio— está incluido en todos los planes. La monitorización de SEO más avanzada, como el seguimiento de posiciones y de enlaces entrantes, se vende como complementos de pago independientes, y la optimización práctica de la velocidad es un extra que se puede adquirir.
Sí. La prueba de Footprint-Free es de 14 días, sin tarjeta y cubre hasta 5 sitios: sin datos de pago y sin compromiso. Implemente algunos sitios y observe lo que realmente informa el panel de control antes de decidir.
Inicie una prueba de 14 días sin tarjeta y consulte el tiempo de actividad, Core Web Vitals, los errores y el uso de recursos por sitio desde el primer despliegue, con alertas donde usted desee. Migraciones gratuitas y una garantía de devolución de dinero de 30 días para respaldar todo.
Empiece gratis