Operación

Operación es donde ves si los sistemas que mantenés están funcionando, y te enterás antes que tu cliente cuando algo falla.

Despliegues

Un despliegue es dónde corre un sistema: la API, la web, un entorno de staging.

• Nombre (“API”, “Web”), solución (obligatoria), cliente y proyecto.
• Entorno: producción, staging o desarrollo.
• Proveedor: Vercel, Cloudflare, un VPS, el servidor del cliente u otro.
• URL, repositorio, notas y responsables.

Precaución

Un despliegue nunca guarda contraseñas, claves ni tokens: solo dónde están. El CRM rechaza incluso una URL con usuario y clave adentro.

Los despliegues se ven en Operación y en las fichas de su solución, su cliente y su proyecto.

El estado

Estado	Qué significa
Operativo	Todos sus chequeos responden.
Degradado	Alguna capa está caída.
Caído	No responde.
En mantenimiento	Hay una ventana de mantenimiento en curso.
Sin chequeos	No tiene chequeos configurados.

Chequeos de salud

Cada despliegue puede tener hasta tres chequeos, que corren cada minuto en el servidor del CRM (no hace falta tener la web abierta):

1. Servidor: la URL pública responde.
2. Backend vivo: /health responde (el proceso está vivo).
3. Backend listo: /health/ready responde (llega a la base y a sus dependencias).

Un chequeo pasa a Caído después de 3 fallos seguidos (configurable) y vuelve a Operativo con el primer éxito. Cada cambio avisa a los responsables del despliegue en menos de 4 minutos. Un chequeo se pausa y se reanuda.

Historial: disponibilidad de las últimas 24 horas, 7 y 30 días, tiempo de respuesta (promedio y p95), la lista de caídas con su duración y un gráfico por día.

Certificados y dominios

Una vez por día, para cada despliegue con https, el CRM lee el vencimiento del certificado SSL y del dominio, y crea su vencimiento técnico en la ficha del cliente. Avisa a los 30 y a los 7 días, y de inmediato si el certificado es inválido. Leer certificado y dominio lo hace en el momento, sin esperar.

Latidos

Un latido vigila una tarea que tiene que correr sola: un backup, un cron, un worker.

1. Creá el latido con su nombre, despliegue, frecuencia esperada (cada N minutos u horas, o diaria a una hora) y tolerancia.
2. El CRM te da una URL secreta y el comando listo para copiar (cron de Linux o paso de GitHub Actions).
3. La tarea llama a esa URL al terminar. Si falla, la llama informando el error.

Si no llega a tiempo, o llega un fallo, es un aviso crítico; cuando vuelve, avisa la recuperación.

Ventanas de mantenimiento

Por despliegue, una ventana con inicio, fin y motivo. Mientras dura, los chequeos siguen pero no avisan, y el estado dice En mantenimiento. Si al terminar algo sigue caído, avisa. Genera el mensaje para el cliente, listo para copiar o mandar por WhatsApp, y aparece en la agenda.

Errores

Tus sistemas le mandan sus errores al CRM (ver Reportar errores). El CRM los agrupa por huella: el mismo error repetido es un solo problema, con su contador, la primera y la última vez.

• Estados: Nuevo, Visto, Resuelto o Ignorado. Uno resuelto que vuelve pasa a Nuevo como “reapareció”.
• Avisa un problema nuevo o reaparecido, y un pico (más de 20 en 5 minutos). Las repeticiones no avisan.
• La ficha muestra la última traza, ejemplos recientes y un gráfico de ocurrencias.

Incidentes

Un incidente se abre solo (un chequeo caído, un latido perdido, un error crítico o reaparecido, un deploy fallido, el agente de servidor) o a mano.

• Tiene título, despliegue, severidad (crítica, alta, media o baja), estado (Abierto, En curso o Resuelto), responsable y una línea de tiempo con comentarios.
• Lo tomo lo pasa a En curso a tu nombre y avisa al resto. Si nadie toma un incidente crítico en 10 minutos, se vuelve a avisar a todos por push y email.
• Crear defecto crea un DEF en el tablero del proyecto o la solución, con la traza y el link al incidente. Al cerrar el defecto, el CRM propone resolver el incidente.
• Al resolver uno crítico o alto, propone un postmortem: qué pasó, la causa, el impacto, qué se hizo y la acción para que no se repita (que puede crear una tarea o una deuda en el tablero).

Se registran el tiempo hasta tomarlo y hasta resolverlo. Mientras está abierto, aparece en el Inicio.

Deploys

Con la integración de GitHub o de Vercel, cada despliegue muestra su último deploy exitoso (versión, commit, fecha y autor). Un deploy fallido abre un incidente que dice en qué paso falló. Los requerimientos nombrados en los commits de un deploy a producción quedan marcados “en producción” con la versión.

Servidores

Con el agente de servidor instalado, cada servidor muestra sus contenedores (estado, reinicios, CPU y memoria) y el disco y la memoria del servidor. Desde la web:

• Pedir logs de un contenedor: el agente los manda en su próximo contacto, sin secretos.
• Acciones remotas (reiniciar un contenedor, liberar espacio), solo las habilitadas en el servidor. Cada una pide confirmación y la aprueba alguien con el permiso Aprobar acciones remotas.

La página de estado para tus clientes

Ver Página de estado.