Mantenimiento y monitoreo

Esta página es para quien opera el servidor, no para quien usa la aplicación. Las tareas del día a día del negocio —crear un empleado, registrar un pago, corregir un horario— están en Uso del sistema.

Trabajo de mantenimiento

Una rutina idempotente que puede ejecutarse tantas veces como haga falta.

Paso	Qué hace
Expirar evidencia	Borra de R2 lo que superó la retención; conserva el historial
Limpiar subidas abandonadas	Elimina metadata de subidas nunca confirmadas (60 min)
Marcar sesiones largas	Señala servicios abiertos más allá del umbral
Purgar sesiones	Borra sesiones caducadas o revocadas hace más de 30 días
Purgar intentos de login	Borra registros de más de 30 días
Purgar notificaciones	Borra notificaciones leídas de más de 90 días

Cada paso está aislado: que falle la limpieza de R2 no impide purgar sesiones. Los fallos se acumulan y se reportan al final.

Nunca cierra sesiones de trabajo ni inventa horas. Sólo marca banderas.

Ejecución

Por HTTP:

curl -X POST -H "Authorization: Bearer $JOBS_SECRET" https://crm.royalcleancr.com/api/jobs/run

Por línea de comandos:

pnpm job:cleanup

Programación recomendada: diaria a las 3:00. Ver Desplegar en Dokploy.

Interpretar el resultado

{
  "durationMs": 106,
  "evidenceExpired": 0,
  "abandonedUploadsRemoved": 0,
  "servicesFlagged": 1,
  "sessionsPurged": 0,
  "loginAttemptsPurged": 0,
  "notificationsPurged": 0,
  "storageConfigured": true,
  "errors": []
}

errors no vacío: revisar los logs. La respuesta HTTP será 500.
storageConfigured: false: faltan variables de R2 y la retención no se está aplicando.
servicesFlagged alto de forma recurrente: el personal olvida finalizar servicios; conviene revisar el flujo o bajar el umbral.

Respaldos

Página aparte, con guion completo de copia y restauración: Respaldos.

Logs

JSON por línea. Para filtrar errores:

docker logs royalclean-app 2>&1 | grep '"level":"error"'

Nunca contienen contraseñas, tokens, secretos, URLs firmadas completas ni códigos de acceso: el saneado es automático por nombre de clave.

LOG_LEVEL acepta debug, info, warn o error. En producción, info.

Salud

curl https://crm.royalcleancr.com/api/health

{"status":"ok","database":"ok","latencyMs":12}

Un 503 significa que la aplicación responde pero no alcanza la base de datos. Revisar el contenedor de PostgreSQL y la red interna.

Crecimiento previsible

Con unos 20 servicios semanales:

Recurso	Al año	Notas
Servicios	~1.000	Trivial para PostgreSQL
Sesiones	~1.500	Trivial
Evidencia	~5.000	Se estabiliza con la retención de 12 meses
Auditoría	~20.000	Vigilar a los 2–3 años
Almacenamiento	~30 GB	Se estabiliza

Nada de esto exige atención especial en el primer par de años. Si la auditoría crece mucho, se puede archivar por rango de fechas sin tocar el resto.

Cuándo pedir ayuda

Síntoma	Dónde mirar
El healthcheck falla	Diagnóstico
Las fotos no cargan	Variables de R2 y logs
El despliegue no arranca	Logs del contenedor; probablemente migraciones
Las cifras no cuadran	Revisar cifras parciales y costos sin registrar
Alguien no puede entrar	¿Cuenta desactivada? ¿Rate limit?

On this page