Estado de la plataforma
Estado en vivo de la plataforma central de Zentor App, consultado directamente desde el backend sin caché.
La página pública de estado muestra la accesibilidad actual de la plataforma central de Zentor App. Consulta directamente y sin caché el endpoint de Health del backend e indica si backend y base de datos son accesibles en ese momento. La página no muestra deliberadamente un porcentaje de uptime inventado ni una evaluación histórica de SLA.
Un estado positivo no significa que cada función de tenant funcione sin errores. Un acceso de WhatsApp puede estar mal configurado, una contraseña SMTP caducada o un dominio no autorizado aunque la plataforma central sea accesible. Proveedores externos como Twilio, PayPal o un proveedor de IA no se comprueban necesariamente por completo mediante el Health Check general.
Ante una incidencia, primero debe consultarse la página de estado. Si informa de un fallo central, realizar cambios repetidos en la configuración local normalmente no tiene sentido. Si la plataforma está accesible, deben seguir diagnósticos del tenant: panel de estado del sistema, botones de prueba de canal y logs. Los logs contienen como máximo 500 líneas y no tienen filtro. En la pestaña Automation Runs no existe botón de Retry.
La visualización es una instantánea. Para una nueva comprobación debe actualizarse la página. No puede demostrar que en un momento anterior no hubiera una incidencia. Para una solicitud de soporte conviene anotar hora, tenant, función afectada, error visible y pasos reproducibles. No deben incluirse secretos ni textos personales de mensajes sin necesidad.
Por tanto, la página de estado solo responde si la plataforma central está accesible en este momento. No sustituye las pruebas de canales ni la comprobación de una instancia SIP aislada. Actualmente no se publica ninguna estadística histórica de disponibilidad ni SLA público.
Si la página no carga en el navegador, también debe comprobarse la conexión local a Internet o la resolución DNS. Un problema de red local puede parecer una caída de plataforma. A la inversa, un endpoint de estado accesible no prueba el funcionamiento de un bundle concreto del frontend. Por eso, la consola del navegador y el protocolo de red forman parte del diagnóstico ampliado.
En incidencias recurrentes resulta útil mantener una serie temporal de observaciones propias, ya que la página pública no guarda historial. Hora, duración y funciones afectadas pueden documentarse internamente. No debe derivarse de ello una cuota oficial de disponibilidad de Zentor mientras no exista una estadística oficial publicada.
Además debe comprobarse si un problema afecta solo a una versión lingüística, a un dispositivo concreto o a todos los usuarios. Esta delimitación ayuda a distinguir causas de frontend, red y backend y evita cambios innecesarios en una configuración de tenant que funciona.
Qué muestra este estado — y qué no
Este estado indica si la plataforma central —backend y base de datos— es accesible. No garantiza que todas las funciones funcionen sin errores para cada tenant ni constituye una estadística histórica de disponibilidad. Actualmente no existe un SLA público para Demo y Starter; en Individual (Individuell) pueden acordarse SLA personalizados — consulte precios.
Estado actual
Cargando estado…
Qué se comprueba
- El proceso del backend está activo y responde.
- La conexión a la base de datos está accesible.
- No hay acumulación de errores desde el último inicio del proceso.
Qué no muestra este estado
- No indica el estado de funciones individuales de tenants ni de integraciones específicas.
- No es una estadística histórica de disponibilidad o uptime — p. ej., «99,9 % el último mes»—; actualmente no existe esa serie de medición.
- No sustituye un SLA contractual. Encontrará detalles sobre SLA en la página de precios.
- El uptime mostrado se refiere al proceso de servidor actualmente activo, no a un historial de disponibilidad a largo plazo.