PayCal Technologies Inc.

Platform metrics transparency

Ipinapakita ng page na ito kung anong telemetry ang kinokolekta ng PayCal, bakit namin ito kinokolekta, at kailan ito dine-delete.

Na-publish:

Ang aming pangako

Dapat makita ng users kung anong telemetry ang kinokolekta ng isang service. Idinodocument ng page na ito ang bawat metric na ginagamit para i-monitor ang platform health.

Aggregate-only ang lahat ng telemetry sa page na ito. Hindi kami nag-i-store ng personal identifiers sa telemetry keys.

Verification metadata

Route metadata

  • Route: /transparency/metrics/
  • Last verified:
  • Next review due:
  • Verification scope: manual content review laban sa current metric key inventory at retention policy.

Known limitations

  • Metric key inventory ay manually kept in sync with code; planned ang automated key-diff tooling para sa quarterly reviews.
  • Retention values ay current configuration defaults at maaaring hindi sumaklaw sa future tenant-specific overrides.

Ina-update ang metadata na ito bilang bahagi ng quarterly audit close-out.

Metric inventory

Metric category Personal data? Retention Purpose
Session lifecycle metrics Hindi 30 days raw, 52 weeks rollup, 24 months monthly User experience at capacity planning
Redis health metrics Hindi 24 hours raw, 7 days hourly, 4 weeks daily Infrastructure reliability
Business aggregates Hindi 30 days daily, 52 weeks weekly, 24 months monthly Growth at planning
Frontend telemetry events Hindi 30 days Error detection at feature health
Encryption operation metrics Hindi 30 days raw, 52 weeks rollup, 24 months monthly Cryptographic reliability

Session lifecycle metrics No personal data

Binibilang namin ang login/logout totals at session duration ranges para maintindihan ang usage patterns. Hindi namin tina-track kung sino ang nag-login.

What: daily login events, logout events, at session duration distributions.

Why: detect authentication issues, reduce friction, at improve capacity planning.

How: daily counters at fixed duration buckets.

Retention: 30 days raw -> 52 weeks rollup -> 24 months monthly -> purge.

Buckets:

  • 0-5min - quick checks
  • 5-30min - typical session
  • 30-60min - extended session
  • 60min+ - long work session

Example keys:

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: session hash ay agad na dini-destroy pagkatapos ng duration calculation. Walang user UUIDs sa telemetry keys.

Volume Cap: maximum 734 keys/year.

Redis health metrics No personal data

Minomonitor namin ang Redis bilang infrastructure health data, hindi user activity data.

What: memory usage, key counts by namespace, at connection stats.

Why: detect memory leaks, prevent evictions, at watch growth.

How: parse Redis INFO output on a scheduled interval.

Retention: 24 hours raw -> 7 days hourly -> 4 weeks daily -> purge.

Namespaces: max 10 tracked 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

Example keys:

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 ay aggregated only. Hindi ini-inspect ang key content.

Volume Cap: 1,680 keys maximum sa active rolling window.

Business aggregate metrics No personal data

Top-level platform totals ito para sa planning, hindi profiling ng individuals.

What: total users, active accounts, average work entries.

Why: capacity planning at growth analysis.

How: daily aggregation ng database counts.

Retention: 30 days daily -> 52 weeks weekly -> 24 months monthly -> purge.

Example keys:

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: aggregate-only values. Walang per-user telemetry records.

Volume Cap: 1,095 keys/year.

Frontend telemetry events No personal data

Event telemetry helps detect client-side failures at feature reliability issues.

What: frontend performance events, error counts, at feature usage events.

Why: identify client issues at monitor product health.

How: POST to /api/telemetry/record for approved event types only.

Retention: 30 days (TTL enforced on increment).

Telemetry submission limits at example event types:

  • 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

Example keys:

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

Privacy Guard: allowlisted ang event types. Walang arbitrary strings o user/session identifiers sa telemetry keys.

Volume Cap: 18,250 keys/year maximum.

Encryption operation metrics No personal data

Cryptographic operations ay minomonitor bilang platform reliability signals.

What: DEK wrap/unwrap success at failure counters.

Why: detect cryptographic failures at misconfiguration quickly.

How: success/failure counters increment for each operation outcome.

Retention: 30 days raw -> 52 weeks rollup -> 24 months monthly -> purge.

Example keys:

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: operation counts lang ang recorded. Walang key material, ciphertext, o personal identifiers na stored.

Volume Cap: 1,460 keys/year.

Retention and compaction pipeline

Raw data: daily counters expire automatically after 30 days.

Weekly rollups: scheduled aggregation to 52-week retention.

Monthly rollups: scheduled aggregation to 24-month retention.

Purge: metrics older than 24 months are deleted.

Compaction script: /scripts/compact-metrics.php.

Enforcement in code

Privacy constraints ay validated by contract tests sa CI.

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

Guardrails: hardcoded namespace/event limits prevent unbounded metric growth.

Additional rate limits:

  • Admin metrics queries: 100 requests/hour
  • Public health checks: 600 requests/hour

Access and verification

Metrics Dashboard: /admin/metrics (authentication and admin role required).

Public Health Endpoint: /api/v1/health returns aggregate platform status.

Last Updated: March 9, 2026.