Purpose
Define what Perfect Wiki logs, how those logs are protected and retained, and how they are monitored to detect and respond to security and availability events.
Scope
Application logs, request logs, audit events of user actions, infrastructure logs from Google Cloud, and error / performance telemetry from Sentry.
What is logged
- HTTP request logs: Source IP, method, URL, status code, response time, user agent — emitted by every API request.
- Application audit events: Page create/update/delete, page view, comment, search query, bot query, publish/unpublish — each tagged with organization, channel, page, author, timestamp.
- Authentication events: Sign-in attempts, session creation, session deletion.
- Error events: Unhandled exceptions, security-relevant errors (auth failures, validation failures, rate-limit hits) captured in Sentry with PII minimization.
- Scheduled job check-ins: Daily reports, weekly backups, page-updates notifications, stale-org cleanup — each emits a Sentry check-in that alerts on failure.
- Infrastructure logs: Google Cloud Audit Logs for IAM changes, Firestore admin operations, Cloud Storage access.
Time synchronization
All systems use Google Cloud's NTP-synchronized clocks; timestamps in logs are UTC.
Protection of logs
- Sentry and Google Cloud Logging are access-restricted to Authorized Personnel via SSO + MFA on the identity provider.
- Logs are append-only at the storage layer; the application does not have credentials to delete log records.
- Personally identifiable information in logs is minimized; passwords are never logged; tokens are masked.
Retention
- Application errors / performance traces: retained per the Sentry plan (typically up to 90 days).
- Google Cloud Audit Logs: retained per Google Cloud's default schedule.
- Application audit events (user actions): retained in Firestore for the lifetime of the organization.
Monitoring & alerting
- Sentry sends real-time alerts on new error issues and on missed cron-job check-ins.
- The status page monitors public endpoint availability and pages on outage.
- Critical alerts are routed to the CEO/CTO; response follows the Incident Response Plan.
Roles & responsibilities
- CEO/CTO: Owns logging configuration and alert routing.
Review cadence
Reviewed annually and after any incident that exposes a logging gap.
Last reviewed: 2026-05-21. Next review: 2027-05-21. Approved by: Ilia Pirozhenko, CEO/CTO.