Skip to main content
Audit logging tracks all configuration changes and data operations within your Bytebase workspace. These logs help you identify who performed what action, when it occurred, and what resources were affected. This enables compliance monitoring, security analysis, and troubleshooting.
Audit logging is available only for Pro and Enterprise plans.

Accessing Audit Logs

GUI

Workspace Admin or DBA can access audit logs through the Bytebase console:
  1. Navigate to the Settings page
  2. Select Audit Log from the sidebar
  3. View the chronological list of all audit events
overview You can filter audit logs by:
  • User
  • Action type
  • Resource
  • Time range
filter filter-date

API

Use the Bytebase API to programmatically access audit logs for integration with external systems and automated monitoring.
For detailed API documentation and examples, see Audit Log API.

Streaming

Stream audit logs to external logging and monitoring systems for centralized management. It supports JSON format output in addition to the default text format.
  1. Navigate to SettingsGeneralAudit Log Export
  2. Enable Enable audit logging to stdout
  3. Save the configuration
Once enabled, all audit events stream to stdout of your Bytebase service. To enable JSON format output, start Bytebase with the --enable-json-logging flag:
Supported integrations:
  • SIEM Platforms: e.g., Splunk, Datadog, Elastic Security
  • Log Aggregators: e.g., Fluentd, Logstash, Grafana Loki
  • Cloud Services: e.g., AWS CloudWatch, Google Cloud Logging, Azure Monitor

Log Structure

Example Entry

Payload Fields

Severity Levels

Status Codes

Status codes follow gRPC conventions:

Audited Events

Notes:
  • Sensitive fields redacted: password, otpCode, recoveryCode, mfaTempToken, idpContext
  • MFA phase logs extract user email from MFA temp token when email is not in request
Notes:
  • User responses redacted to only include: name, email, title, userType
Notes:
  • IAM policy changes include serviceData with PolicyDelta showing added/removed bindings
Notes:
  • Includes serviceData with PolicyDelta showing added/removed bindings
Notes:
  • DataSource sensitive fields redacted: password, sslCa, sslCert, sslKey, sshPassword, sshPrivateKey, authenticationPrivateKey, externalSecret, saslConfig.krbConfig.keytab, masterPassword
Notes:
  • Response rows completely redacted - only metadata captured: columnNames, columnTypeNames, rowsCount, error, latency, statement
  • Each request/response pair in streaming operations generates a separate audit log
  • Export request password field redacted; response content not logged

Events Not Logged

Retention

Bytebase does not automatically purge audit logs. You must implement periodic cleanup to prevent disk space exhaustion, which can cause Bytebase to crash.
Audit logs are stored in the audit_log table in the Bytebase metadata database. Recommended retention periods:
  • Minimum: 90 days
  • Compliance environments: 6–12 months
Cleanup options:
  • Manually delete old logs from the audit_log table
  • Set up a scheduled job using pg_cron or system cron
  • Export logs to external log management or SIEM systems for longer-term retention

Limitations

Privacy and Security

  • Query results excluded: Actual row data from queries is redacted
  • Sensitive data masking: Passwords, API keys, SSL certificates, SSH keys automatically replaced with masked values
  • Response truncation: Large response payloads may be omitted

Technical Constraints

  • Synchronous generation: Audit logs are generated during request processing
  • Pagination limit: Maximum 5,000 entries per API call
  • Filter complexity: Searches must use valid CEL expressions
  • Storage: Logs stored in metadata database, following its retention policies