PayCal Technologies Inc.

Transparantie van platformstatistieken

Deze pagina toont welke telemetrie PayCal verzamelt, waarom we die verzamelen en wanneer die wordt verwijderd.

Gepubliceerd:

Onze inzet

Gebruikers moeten precies kunnen zien welke telemetrie een dienst verzamelt. Deze pagina documenteert elke metriek die platformgezondheid bewaakt.

Alle telemetrie op deze pagina is alleen geaggregeerd. We slaan geen persoonlijke identifiers op in telemetriesleutels.

Verificatiemetadata

Routemetadata

  • Route: /transparency/metrics/
  • Laatst geverifieerd:
  • Volgende review:
  • Verificatiescope: handmatige contentreview tegen huidige metriek-key-inventaris en retentiebeleid.

Bekende beperkingen

  • De metriek-key-inventaris wordt handmatig met code gesynchroniseerd; automatische key-diff tooling is gepland voor kwartaalreviews.
  • Retentiewaarden volgen huidige configuratiestandaarden en kunnen toekomstige tenant-specifieke overrides niet weerspiegelen.

Deze metadata wordt bijgewerkt als onderdeel van de kwartaalafsluiting van de audit.

Metriekinventaris

Metriekcategorie Persoonlijke gegevens? Retentie Doel
Sessielifecycle-metrieken Nee 30 dagen raw, 52 weken rollup, 24 maanden maandelijks Gebruikerservaring en capaciteitsplanning
Redis-gezondheidsmetrieken Nee 24 uur raw, 7 dagen per uur, 4 weken dagelijks Infrastructuurbetrouwbaarheid
Businessaggregaten Nee 30 dagen dagelijks, 52 weken wekelijks, 24 maanden maandelijks Groei en planning
Frontend-telemetrieevents Nee 30 dagen Foutdetectie en featuregezondheid
Encryptie-operatiemetrieken Nee 30 dagen raw, 52 weken rollup, 24 maanden maandelijks Cryptografische betrouwbaarheid

Sessielifecycle-metrieken Geen persoonlijke gegevens

We tellen login-/logouttotalen en sessieduurbereiken om gebruikspatronen te begrijpen. We volgen niet wie inlogde.

Wat: dagelijkse login-events, logout-events en sessieduurdistributies.

Waarom: authenticatieproblemen detecteren, frictie verminderen en capaciteitsplanning verbeteren.

Hoe: dagelijkse counters en vaste duration buckets.

Retentie: 30 dagen raw -> 52 weken rollup -> 24 maanden maandelijks -> purge.

Buckets:

  • 0-5min - snelle controles
  • 5-30min - typische sessie
  • 30-60min - verlengde sessie
  • 60min+ - lange werksessie

Voorbeeldsleutels:

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: de sessiehash wordt direct na de duurberekening vernietigd. Geen gebruikers-UUIDs in telemetriesleutels.

Volumelimiet: maximaal 734 sleutels/jaar.

Redis-gezondheidsmetrieken Geen persoonlijke gegevens

We monitoren Redis als infrastructuurgezondheid, niet als gebruikersactiviteit.

Wat: geheugengebruik, key counts per namespace en connectiestatistieken.

Waarom: memory leaks detecteren, evictions voorkomen en groei volgen.

Hoe: Redis INFO-output op schema parsen.

Retentie: 24 uur raw -> 7 dagen per uur -> 4 weken dagelijks -> purge.

Namespaces: maximaal 10 gevolgde namespaces (hardcoded whitelist).

  • 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

Voorbeeldsleutels:

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: namespace counts zijn alleen geaggregeerd. Key-inhoud wordt niet bekeken.

Volumelimiet: maximaal 1.680 sleutels in het actieve rolling window.

Businessaggregaatmetrieken Geen persoonlijke gegevens

Dit zijn platformtotalen voor planning, niet om individuen te profileren.

Wat: totaal gebruikers, actieve accounts, gemiddelde work entries.

Waarom: capaciteitsplanning en groeianalyse.

Hoe: dagelijkse aggregatie van databasecounts.

Retentie: 30 dagen dagelijks -> 52 weken wekelijks -> 24 maanden maandelijks -> purge.

Voorbeeldsleutels:

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: alleen aggregaatwaarden. Geen telemetrierecords per gebruiker.

Volumelimiet: 1.095 sleutels/jaar.

Frontend-telemetrieevents Geen persoonlijke gegevens

Eventtelemetrie helpt client-side failures en featurebetrouwbaarheid te detecteren.

Wat: frontend performance events, foutcounts en feature usage events.

Waarom: clientproblemen vinden en productgezondheid monitoren.

Hoe: POST naar /api/telemetry/record alleen voor goedgekeurde eventtypes.

Retentie: 30 dagen (TTL bij increment afgedwongen).

Limieten voor verzending en voorbeeld-eventtypes:

  • 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

Voorbeeldsleutels:

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

Privacy Guard: eventtypes staan op een allowlist. Geen arbitraire strings of gebruikers-/sessie-identifiers in telemetriesleutels.

Volumelimiet: maximaal 18.250 sleutels/jaar.

Encryptie-operatiemetrieken Geen persoonlijke gegevens

Cryptografische operaties worden gemonitord als signalen voor platformbetrouwbaarheid.

Wat: DEK wrap/unwrap success- en failure-counters.

Waarom: cryptografische fouten en misconfiguratie snel detecteren.

Hoe: success/failure counters verhogen per operatie-uitkomst.

Retentie: 30 dagen raw -> 52 weken rollup -> 24 maanden maandelijks -> purge.

Voorbeeldsleutels:

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: alleen operatiecounts worden opgeslagen. Geen key material, ciphertext of persoonlijke identifiers.

Volumelimiet: 1.460 sleutels/jaar.

Retentie- en compactiepipeline

Raw data: dagelijkse counters verlopen automatisch na 30 dagen.

Wekelijkse rollups: geplande aggregatie naar 52 weken retentie.

Maandelijkse rollups: geplande aggregatie naar 24 maanden retentie.

Purge: metrieken ouder dan 24 maanden worden verwijderd.

Compactiescript: /scripts/compact-metrics.php.

Afdwinging in code

Privacyvoorwaarden worden gevalideerd door contracttests in CI.

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

Guardrails: hardcoded namespace-/eventlimieten voorkomen onbegrensde metriekgroei.

Aanvullende rate limits:

  • Admin-metriekquery’s: 100 requests/uur
  • Publieke health checks: 600 requests/uur

Toegang en verificatie

Metriekdashboard: /admin/metrics (authenticatie en adminrol vereist).

Publiek health endpoint: /api/v1/health geeft geaggregeerde platformstatus terug.

Laatst bijgewerkt: 9 maart 2026.