PayCal Technologies Inc.

Transparencia de métricas de plataforma

Esta página muestra qué telemetría recopila PayCal, por qué la recopilamos y cuándo se elimina.

Publicado:

Nuestro compromiso

Los usuarios deberían poder ver exactamente qué telemetría recopila un servicio. Esta página documenta cada métrica usada para monitorear la salud de la plataforma.

Toda la telemetría de esta página es solo agregada. No almacenamos identificadores personales en claves de telemetría.

Metadatos de verificación

Metadatos de ruta

  • Ruta: /transparency/metrics/
  • Última verificación:
  • Próxima revisión:
  • Alcance de verificación: revisión manual contra el inventario actual de claves métricas y la política de retención.

Limitaciones conocidas

  • El inventario de claves métricas se mantiene manualmente sincronizado con el código; se planean herramientas automáticas de key-diff para revisiones trimestrales.
  • Los valores de retención reflejan la configuración predeterminada actual y pueden no reflejar overrides por tenant si se agregan en el futuro.

Estos metadatos se actualizan como parte del cierre de auditoría trimestral.

Inventario de métricas

Categoría de métrica ¿Datos personales? Retención Propósito
Métricas de ciclo de vida de sesión No 30 días raw, 52 semanas rollup, 24 meses mensual Experiencia de usuario y planificación de capacidad
Métricas de salud de Redis No 24 horas raw, 7 días por hora, 4 semanas diario Confiabilidad de infraestructura
Agregados de negocio No 30 días diario, 52 semanas semanal, 24 meses mensual Crecimiento y planificación
Eventos de telemetría frontend No 30 días Detección de errores y salud de features
Métricas de operaciones de cifrado No 30 días raw, 52 semanas rollup, 24 meses mensual Confiabilidad criptográfica

Métricas de ciclo de vida de sesión Sin datos personales

Contamos totales de login/logout y rangos de duración de sesión para entender patrones de uso. No rastreamos quién inició sesión.

Qué: eventos diarios de login, logout y distribuciones de duración de sesión.

Por qué: detectar problemas de autenticación, reducir fricción y mejorar planificación de capacidad.

Cómo: contadores diarios y buckets fijos de duración.

Retención: 30 días raw -> 52 semanas rollup -> 24 meses mensual -> purga.

Buckets:

  • 0-5min - revisiones rápidas
  • 5-30min - sesión típica
  • 30-60min - sesión extendida
  • 60min+ - sesión larga de trabajo

Claves de ejemplo:

telemetry:auth:login:2026-03-09      -> 247
telemetry:auth:logout:2026-03-09     -> 219
telemetry:session:duration:0-5min    -> 45
telemetry:session:duration:5-30min   -> 128
telemetry:session:duration:30-60min  -> 39
telemetry:session:duration:60min+    -> 7

Privacy Guard: el hash de sesión se destruye inmediatamente después del cálculo de duración. No se almacenan UUIDs de usuario en claves de telemetría.

Límite de volumen: máximo 734 claves/año.

Métricas de salud de Redis Sin datos personales

Monitoreamos Redis como datos de salud de infraestructura, no como datos de actividad de usuario.

Qué: uso de memoria, conteos de claves por namespace y estadísticas de conexión.

Por qué: detectar fugas de memoria, prevenir evictions y observar crecimiento.

Cómo: parsear salida Redis INFO en intervalos programados.

Retención: 24 horas raw -> 7 días por hora -> 4 semanas diario -> purga.

Namespaces: máximo 10 namespaces rastreados (allowlist fija).

  • session:* - Active sessions
  • lock:* - Distributed locks
  • cache:* - Application cache
  • telemetry:* - Metrics storage
  • ratelimit:* - Rate limiting counters
  • nonce:* - CSRF tokens
  • temp:* - Temporary data
  • queue:* - Job queues
  • encryption:* - Wrapped keys
  • feature:* - Feature flags

Claves de ejemplo:

telemetry:redis:memory:used_mb:2026-03-09:14  -> 247
telemetry:redis:keys:session:2026-03-09:14    -> 342
telemetry:redis:keys:lock:2026-03-09:14       -> 18

Privacy Guard: los conteos por namespace son solo agregados. El contenido de claves no se inspecciona.

Límite de volumen: máximo 1.680 claves en la ventana rolling activa.

Métricas agregadas de negocio Sin datos personales

Son totales de plataforma usados para planificación, no para perfilar personas.

Qué: usuarios totales, cuentas activas, promedio de work entries.

Por qué: planificación de capacidad y análisis de crecimiento.

Cómo: agregación diaria de conteos de base de datos.

Retención: 30 días diario -> 52 semanas semanal -> 24 meses mensual -> purga.

Claves de ejemplo:

telemetry:business:users:total:2026-03-09     -> 1247
telemetry:business:users:active:2026-03-09    -> 892
telemetry:business:work:avg_per_user:2026-03  -> 23.4

Privacy Guard: valores solo agregados. Sin registros de telemetría por usuario.

Límite de volumen: 1.095 claves/año.

Eventos de telemetría frontend Sin datos personales

La telemetría de eventos ayuda a detectar fallas client-side y problemas de confiabilidad de features.

Qué: eventos de rendimiento frontend, conteos de errores y uso de features.

Por qué: identificar problemas del cliente y monitorear salud del producto.

Cómo: POST a /api/telemetry/record solo para tipos de evento aprobados.

Retención: 30 días (TTL aplicado al incrementar).

Límites de envío y tipos de evento de ejemplo:

  • 90 events/minute per client (abuse prevention)
  • calendar.load.success
  • calendar.load.failure
  • encryption.dek.unwrap.success
  • encryption.dek.unwrap.failure
  • passkey.login.success
  • passkey.login.failure

Claves de ejemplo:

telemetry:event:calendar.load.success:2026-03-09    -> 3421
telemetry:event:passkey.login.failure:2026-03-09    -> 17

Privacy Guard: los tipos de evento están allowlisted. Sin strings arbitrarios ni identificadores de usuario/sesión en claves de telemetría.

Límite de volumen: máximo 18.250 claves/año.

Métricas de operaciones de cifrado Sin datos personales

Las operaciones criptográficas se monitorean como señales de confiabilidad de plataforma.

Qué: contadores de éxito y fallo de DEK wrap/unwrap.

Por qué: detectar rápidamente fallos criptográficos y configuración incorrecta.

Cómo: contadores de éxito/fallo incrementan por cada resultado de operación.

Retención: 30 días raw -> 52 semanas rollup -> 24 meses mensual -> purga.

Claves de ejemplo:

telemetry:encryption:dek:wrap:success:2026-03-09      -> 1203
telemetry:encryption:dek:wrap:failure:2026-03-09      -> 2
telemetry:encryption:dek:unwrap:success:2026-03-09    -> 5847
telemetry:encryption:dek:unwrap:failure:2026-03-09    -> 31

Privacy Guard: solo se registran conteos de operaciones. No se almacena material de clave, ciphertext ni identificadores personales.

Límite de volumen: 1.460 claves/año.

Pipeline de retención y compactación

Datos raw: los contadores diarios expiran automáticamente después de 30 días.

Rollups semanales: agregación programada a retención de 52 semanas.

Rollups mensuales: agregación programada a retención de 24 meses.

Purga: métricas mayores a 24 meses se eliminan.

Script de compactación: /scripts/compact-metrics.php.

Aplicación en código

Las restricciones de privacidad se validan con contract tests en CI.

MetricsPrivacyContractTest::testSessionDurationHasExactlyFourBuckets()
MetricsPrivacyContractTest::testNoUserUUIDsInTelemetryKeys()
MetricsPrivacyContractTest::testRedisNamespacesNeverExceedTen()
MetricsPrivacyContractTest::testAllTelemetryKeysHaveTTL()

Guardrails: límites fijos de namespace/evento evitan crecimiento no acotado de métricas.

Rate limits adicionales:

  • Consultas admin de métricas: 100 solicitudes/hora
  • Health checks públicos: 600 solicitudes/hora

Acceso y verificación

Dashboard de métricas: /admin/metrics (requiere autenticación y rol admin).

Endpoint público de salud: /api/v1/health devuelve estado agregado de plataforma.

Última actualización: 9 de marzo de 2026.