Event Logs

Audit trail of workspace events for compliance, security monitoring, and troubleshooting.

Provisionr maintains a comprehensive, immutable audit trail of every action taken within your workspace. Every identity sync, policy evaluation, group membership change, API call, and administrative action is recorded with structured metadata to support compliance, troubleshooting, and operational visibility.

Event logging is not an optional feature or add-on. It is built into the core of Provisionr and runs automatically for every workspace on every plan. You do not need to enable it, configure it, or install anything. Every operation that changes state in your workspace — whether initiated by a user, a scheduled job, the REST API, or the Admin CLI — produces an event log entry from the moment your workspace is created.

How Event Logging Works

Every operation in Provisionr generates one or more event log entries stored in your workspace’s audit_logs table. Events are written synchronously at the time of execution and are append-only — once created, an event cannot be modified or deleted by any user, administrator, or Provisionr employee.

Each event captures who performed the action, what changed, when it happened, and why. For automated operations like scheduled syncs, the system records the job context, performance metrics, and the policy rules that triggered the change.

When a single operation affects multiple records, Provisionr generates individual event log entries for each record. For example, if a policy sync adds 12 users to an Okta group and removes 3, the system creates 15 separate event log entries — one for each membership change — all linked by a shared job_id and job_batch identifier. This granularity allows you to trace exactly what happened to each user while still being able to view the operation as a whole.

Events are written to the database within the same transaction as the operation itself. If an operation fails and is rolled back, the corresponding event is still recorded with an error result, ensuring that failed operations are visible in your audit trail rather than silently disappearing.

Event Types

Provisionr uses a structured event type format with dot notation to classify every event. This format provides consistent, searchable identifiers across all operations:

provider.entity.action.result.reason

Each segment serves a specific purpose:

Segment	Purpose	Examples
provider	The system or vendor involved	okta, google, slack, gitlab, aws, provisionr
entity	The type of resource being acted upon	group, user, usergroup, policy, workspace, identity
action	The operation performed	add_user, remove_user, sync, create, update, delete
result	Whether the operation succeeded or failed	success, error, skip
reason	Additional context about the result	ok, rate_limit, not_found, already_exists, unauthorized

For example:

Event Type	Description
okta.group.add_user.success.ok	User added to an Okta group successfully
okta.group.add_user.error.rate_limit	Adding a user to an Okta group failed due to API rate limiting
okta.group.add_user.skip.already_exists	User was already a member of the Okta group; no action taken
google.group.remove_user.success.ok	User removed from a Google Workspace group
google.group.remove_user.error.not_found	User could not be removed because they were not found in the group
slack.usergroup.add_user.error.rate_limit	Adding a user to a Slack User Group failed due to rate limiting
gitlab.group.add_user.success.ok	User added to a GitLab group
gitlab.project.add_user.success.ok	User added to a GitLab project
aws.identitycenter.add_user.success.ok	User added to an AWS Identity Center group
provisionr.policy.sync.success.ok	Policy sync completed successfully
provisionr.policy.create.success.ok	New policy created
provisionr.identity.sync.success.ok	Identity sync completed successfully
provisionr.workspace.setting.update.success.ok	Workspace setting updated
provisionr.token.create.success.ok	New API token or service account created
provisionr.auth.login.success.ok	User signed in to the workspace
provisionr.auth.login.error.unauthorized	Failed sign-in attempt

The five segments provide granular filtering. You can search all okta.* events to see every Okta operation, all *.*.*.error.* events to find failures across every provider, all *.group.add_user.*.* events to see every group addition regardless of vendor, or drill into a specific event type for investigation. Wildcard filtering is supported across the web interface, CLI, and API.

The skip result is an important distinction from success and error. A skip indicates that Provisionr evaluated an operation, determined it was unnecessary (because the desired state already existed), and took no action. Skips are logged so that you have a complete picture of what Provisionr evaluated during a sync, even when no changes were needed. This is particularly useful for verifying that policies are being evaluated correctly and that your group memberships are already in the expected state.

Note: For the complete list of event types used in your workspace, see the Event Log CLI Reference.

What Gets Logged

Identity Sync Events

The Identity Sync fetches your user directory from your identity provider (Okta, Google Workspace, etc.) and caches it in your Provisionr workspace. This sync detects new users, attribute changes, deactivations, and changes to the dimensions and attributes that drive your policies.

Every time an Identity Sync runs, the following is recorded:

• Each user created, updated, or deactivated, with the specific attributes that changed and their old and new values
• Dimension and attribute changes detected, such as new departments appearing in your HRIS data, deprecated job titles, new cost centers, or reorganized teams
• The total number of users evaluated, the number of changes detected, and the number of API calls made to your identity provider
• Sync duration and performance metrics, including total elapsed time, per-record processing time, and API response latency
• Any errors or rate limits encountered during the sync, including the specific API endpoint, HTTP status code, and retry behavior
• The job identifier and batch identifier linking all events from this sync together

Identity Sync events use the provisionr.identity.* event type prefix. Individual user change events within the sync reference the upstream provider (e.g., okta.user.update.success.ok) to indicate which vendor’s data changed.

If the Identity Sync encounters a rate limit from your identity provider, Provisionr logs the rate limit event, backs off according to the vendor’s retry-after header, and resumes. The rate limit event is logged with the error.rate_limit result, and the subsequent successful retry is logged as a separate event, giving you full visibility into the sync’s behavior.

Policy Sync Events

The Policy Sync evaluates each of your policies against the cached user directory and updates group memberships across your connected vendors. This is where Provisionr performs the actual provisioning work — adding and removing users from Google Groups, Okta Groups, Slack User Groups, GitLab Groups, AWS Identity Center Groups, and other resources.

When a Policy Sync runs, events are logged for:

• Each user who newly qualifies for a policy and is added to the corresponding group, including which rules and conditions matched
• Each user who no longer qualifies and is removed from the group, including which rules or conditions they no longer satisfy
• Each user who was evaluated and skipped because their membership already matched the policy’s expected state
• The vendor API calls made for each membership change, including the HTTP method, endpoint, response status, and response time
• Per-policy sync duration, including the time spent evaluating rules, the time spent making API calls, and the total number of records processed
• The manifest comparison between the policy’s expected membership list and the vendor group’s actual membership list, showing additions, removals, and unchanged members

Policy Sync events use two event type patterns. The orchestration events use provisionr.policy.sync.* to indicate the overall sync job status. The individual membership change events use the vendor prefix (e.g., okta.group.add_user.success.ok, google.group.remove_user.success.ok) to indicate the specific API call made to the vendor.

All events from a single policy sync share the same job_id, and all events from a scheduled sync run (which evaluates all policies) share the same job_batch. This lets you view a single policy’s sync results or the entire scheduled sync as a cohesive unit.

Administrative Events

All administrative actions within your workspace are logged, whether performed through the web interface, CLI, or API. Administrative events provide a complete record of who changed your workspace configuration and when.

The following administrative actions generate event log entries:

• Authentication: User sign-ins (including SSO), failed sign-in attempts, session creation and expiration, and multi-factor authentication events
• Policy management: Policy creation, modification (including rule and condition changes), activation, deactivation, and deletion, with before and after values for each changed field
• Workspace settings: Changes to workspace name, sync frequency, notification preferences, telemetry settings, connected vendor configurations, and any other workspace-level setting
• Token and credential management: API token creation, rotation, and revocation; service account creation and deletion; CLI token issuance and expiration
• Team management: Invitations sent to new team members, role assignments and changes, team member removal
• Data operations: Data exports initiated (including the format, filters, and requesting user), data imports, and bulk operations
• Billing events: Subscription plan changes, payment method updates, invoice generation, and billing contact changes

Each administrative event records the authenticated user who performed the action, the specific fields that changed (with old and new values where applicable), the interface used (web, CLI, or API), and the IP address and user agent of the request.

API and CLI Events

Operations performed via the REST API or Admin CLI are logged with the same fidelity as operations performed through the web interface. There is no difference in audit coverage between interfaces — the same event types, fields, and metadata are recorded regardless of how the operation was initiated.

For API requests, each event log entry includes:

• The authenticated identity — whether a user session, a service account, a personal access token (PAT), or a CLI token
• The token identifier (not the token value itself) so you can trace activity back to the specific credential used
• The API endpoint, HTTP method, and request parameters
• The response status code and response time
• Rate limit headers and remaining quota (if applicable)

For CLI operations, the event log additionally records the CLI version and the command that was executed. This is useful for troubleshooting when a team member reports unexpected behavior from a CLI session.

Vendor API Events

Every API call that Provisionr makes to an external vendor on your behalf is logged as an event. This provides complete visibility into how Provisionr interacts with your connected systems and is invaluable for troubleshooting integration issues.

Vendor API events capture:

• The vendor, API endpoint, HTTP method, and request payload (with sensitive values masked)
• The HTTP response status code, response time in milliseconds, and any error messages returned by the vendor
• Rate limit headers from the vendor’s response, including remaining quota and reset time
• The Provisionr operation that triggered the API call (linked via job_id to the parent sync or user action)
• Request identifiers from the vendor’s response headers (e.g., Okta’s x-okta-request-id) for cross-referencing with the vendor’s own logs

If a vendor API call fails and Provisionr retries it, each attempt is logged as a separate event. The retry events include the retry attempt number and the backoff delay, so you can see exactly how Provisionr handled transient failures.

Webhook Events

If your workspace uses webhooks to integrate with external systems or no-code workflow platforms, each webhook dispatch is logged as an event. Webhook events record the destination URL, the payload sent (with sensitive values masked), the HTTP response status from the receiving system, and delivery latency. Failed webhook deliveries and subsequent retries are logged as separate events.

Event Log Schema

Each event log entry contains a consistent set of fields. Not all fields are populated for every event — for example, attribute_key and attribute_value_old are only present for update events that change a specific attribute, and job_id is only present for events triggered by background jobs.

Field	Type	Description
id	ULID	Unique event identifier, sortable by creation time
event_type	String	Structured event type in dot notation (e.g., okta.group.add_user.success.ok)
timestamp	ISO 8601	When the event occurred, with millisecond precision
workspace_id	ULID	The workspace where the event occurred
actor_id	ULID	The user, service account, or system process that triggered the event
actor_type	Enum	The type of actor: user, service_account, system, cli_token, pat, or webhook
record_type	String	The type of record affected (e.g., user, group, policy, workspace)
record_id	ULID	The Provisionr identifier of the affected record
parent_type	String	Parent entity type for hierarchical context (e.g., policy for a group membership event)
parent_id	ULID	Parent entity identifier
provider_id	String	External vendor record identifier (e.g., Okta user ID, Google group email, GitLab group ID)
reference_value	String	Human-readable reference for the record (e.g., user email, group name)
attribute_key	String	The attribute that changed (for update events)
attribute_value_old	String	Previous value of the attribute
attribute_value_new	String	New value of the attribute
event_ms	Integer	Event processing duration in milliseconds
duration_ms	Integer	Total operation duration in milliseconds (including API calls)
job_id	ULID	Background job identifier (for scheduled and queued operations)
job_batch	ULID	Batch identifier grouping all jobs in a single sync run
hash	String	Cryptographic hash of the event for integrity verification
previous_hash	String	Hash of the preceding event, forming a verifiable chain
metadata	JSON	Additional structured context (varies by event type)

The metadata JSON field contains event-type-specific information that doesn’t fit into the standard schema. For vendor API events, this includes HTTP status codes, response headers, and request identifiers. For policy sync events, this includes the rule evaluation results and manifest comparison details. The structure of metadata varies by event type and is documented in the Event Log CLI Reference.

Understanding ULIDs

Provisionr uses ULIDs (Universally Unique Lexicographically Sortable Identifiers) for all event and record identifiers. ULIDs encode a millisecond-precision timestamp in their first 10 characters, which means they are naturally sortable by creation time. An event with ID 01JR38CZ5YBR8HFYE6J2VP4GC7 was created before an event with ID 01JR38DN3W5CVPQRAXE2P5XF19 because the first 10 characters sort lexicographically. This makes cursor-based pagination efficient and allows you to estimate when an event was created from its ID alone.

Sensitive Data Handling

Provisionr takes a deliberate approach to what is and is not stored in event logs. The goal is to provide enough information for compliance and troubleshooting while avoiding unnecessary exposure of sensitive data.

What Is Masked

Sensitive values are automatically masked before being written to the event log. You do not need to configure masking — it is applied by default. The following types of data are always masked:

• API tokens and secrets: Token values are never stored. Event logs reference tokens by their identifier (e.g., pat_01JR...) rather than the token string itself.
• Passwords and credentials: Any credential value passing through the system is replaced with a masked placeholder before logging.
• Vendor API keys: Your connected vendor credentials (OAuth tokens, API keys, client secrets) are never included in event log entries.

What Is Logged in Cleartext

Certain user attributes are logged in cleartext because they are essential for the audit trail to be meaningful:

• Email addresses: Logged as part of user identification and group membership changes. Knowing that [e-mail] was added to the engineering group is the core purpose of the audit log.
• User names and display names: Logged alongside email addresses for human readability.
• Group names and identifiers: The names and vendor-side identifiers of groups and resources being managed.
• Attribute values used in policy rules: When a user’s department changes from “Sales” to “Engineering” and triggers a policy re-evaluation, both values are logged so you can understand why the membership changed.

PII Considerations

Event logs contain PII by design — names, email addresses, and organizational attributes are fundamental to an audit trail for identity governance. This data is stored within your workspace’s isolated database and is subject to the same access controls, encryption at rest, and retention policies as all other workspace data.

If your organization has specific requirements around PII in audit logs (such as pseudonymization for GDPR), contact us to discuss your needs.

Viewing Event Logs

Event logs are accessible in your workspace through several interfaces. All interfaces provide the same underlying data — the difference is in how you interact with it.

Web Interface

Navigate to the Event Logs section in your workspace to browse, search, and filter events. The web interface provides a paginated list of events with the most recent events displayed first.

You can filter events by:

• Event type — Use the full dot notation or wildcards (e.g., okta.group.* to see all Okta group operations)
• Date range — Select a start and end date to narrow results to a specific time window
• Actor — Filter by a specific user, service account, or system process
• Record — Filter by the affected record (e.g., a specific user, group, or policy)
• Result — Show only successes, errors, or skips
• Job — Filter by job identifier or batch identifier to see all events from a specific sync run

Each event can be expanded to view the full metadata, including the attribute changes, API response details, and performance metrics. From the expanded view, you can navigate to related events (e.g., all events in the same job batch) or to the affected record’s detail page.

Admin CLI

Use the CLI client to query event logs from your terminal. The CLI is useful for scripting, automation, and quick lookups without leaving your workflow.

# List recent events filtered by type
provisionr events list --type "okta.group.*" --since "2026-01-01"

# Find all errors in the last 24 hours
provisionr events list --result "error" --since "24h"

# List events from a specific sync job
provisionr events list --job "01JR38CZ5YBR8HFYE6J2VP4GC7"

# List events for a specific user
provisionr events list --record-type "user" --record-id "01JR38DN3W5CVPQRAXE2P5XF19"

# View a single event with full metadata
provisionr events show evt_01JR38CZ5YBR8HFYE6J2VP4GC7

# Export events to JSON
provisionr events list --type "provisionr.auth.*" --since "2026-01-01" --format json > auth-events.json

REST API

Query event logs through the API for integration with your own tools, dashboards, and automated workflows. The API returns paginated JSON responses with cursor-based pagination using ULID ordering.

GET /api/v1/events?type=okta.group.*&since=2026-01-01T00:00:00Z&limit=100
GET /api/v1/events?result=error&since=2026-02-01T00:00:00Z
GET /api/v1/events?job_batch=01JR38CZ5YBR8HFYE6J2VP4GC7
GET /api/v1/events/{event_id}

The API supports the same filtering parameters as the web interface and CLI. Responses include pagination cursors for efficient traversal of large result sets. See the API Reference for the complete endpoint documentation.

Exporting Event Logs

You can export event logs from your workspace for offline analysis, compliance reporting, long-term archival, or integration with external tools. Exports are available on all plans.

Format	Use Case
JSON	Complete data export for programmatic processing, SIEM ingestion, or archival
CSV	Tabular export for spreadsheet analysis, reporting, and sharing with non-technical stakeholders
YAML	Human-readable export for configuration review and documentation
API	Programmatic access for continuous integration with external systems and automated pipelines

Exports can be filtered by date range, event type, actor, record, result, and job identifiers. All exports include the full event metadata for each event. Exports are generated as downloadable files from the web interface or streamed as paginated responses from the API.

Export Size and Performance

For workspaces with large volumes of events, exports are chunked into manageable files. The web interface generates a ZIP archive containing multiple JSON or CSV files if the export exceeds 100,000 events. The API streams results with cursor-based pagination, allowing you to process events incrementally without loading the entire dataset into memory.

Scheduled Exports

Growth and Scale plan customers can configure scheduled exports that run automatically and deliver event log files to a destination of your choice. This is useful for maintaining a continuous archive of event logs in your own storage or for feeding a regular compliance reporting pipeline.

SIEM Integration (Scale Plan)

Scale plan customers receive direct access to event log data in Amazon S3 for integration with your Security Information and Event Management (SIEM) platform. Because Scale plan workspaces run on dedicated AWS infrastructure, event logs are written to an S3 bucket in your dedicated AWS account, giving you full control over access, retention, and lifecycle management.

Event logs are written to S3 in near real-time as operations occur. S3 event log files are structured in a predictable path format for easy ingestion:

s3://provisionr-audit-{workspace_id}/events/{year}/{month}/{day}/{hour}/

Each hourly partition contains one or more JSON files with the event log entries for that hour. Files are written in newline-delimited JSON (NDJSON) format, which is natively supported by most SIEM platforms.

Supported SIEM Platforms

The S3-based event log format is compatible with any SIEM that supports S3 ingestion, including:

• Splunk — Use the Splunk Add-on for AWS to ingest from the S3 bucket with SQS notifications
• Datadog — Configure an S3 log source with the Datadog Forwarder Lambda function
• Elastic / OpenSearch — Use Filebeat or Logstash with the S3 input plugin
• Sumo Logic — Configure an S3 source in a Hosted Collector
• Microsoft Sentinel — Use the S3 connector via the Azure Monitor Agent or a custom Lambda forwarder
• Chronicle (Google SecOps) — Configure an S3 feed with the Chronicle ingestion API

S3 Event Notifications

Your S3 bucket is configured with event notifications that trigger when new event log files are written. You can subscribe an SQS queue, SNS topic, or Lambda function to these notifications to process events in near real-time as they arrive.

Access Control

You control access to your S3 event log bucket through standard AWS IAM policies. Provisionr’s service role has write-only access to deliver event logs. Your team manages read access through your own IAM policies, allowing you to grant access to your SIEM service account, security team, or compliance auditors without involving Provisionr.

Retention Policies

Event log retention varies by plan. Retention is enforced automatically — you do not need to configure cleanup jobs or manage storage.

Plan	Retention Period	Storage	SIEM Access
Baseline	90 days	Shared infrastructure	Not available
Growth	3 years	Shared infrastructure	Not available
Scale	3 years (default), configurable	Dedicated AWS account	S3 bucket with full access

Baseline Plan (90 Days)

Events older than 90 days are permanently deleted on a rolling basis. If you need to retain event logs beyond 90 days for compliance or operational purposes, we recommend setting up a regular export schedule (weekly or monthly) to archive events in your own storage before they expire.

Growth Plan (3 Years)

Three years of event log history is retained by default. This meets the retention requirements for most compliance frameworks, including SOC 2 and ISO 27001. Events older than 3 years are permanently deleted on a rolling basis.

Scale Plan (3 Years + Configurable)

Scale plan customers retain 3 years of event log history in the Provisionr application by default, with the option to configure custom retention periods. Because Scale plan event logs are also written to S3 in your dedicated AWS account, you can manage S3 lifecycle policies independently to extend retention to 7 years (common for financial compliance and HIPAA), 10 years, or indefinitely. The S3 bucket’s retention policy is entirely under your control and is independent of the application-level retention.

Scale plan customers can also configure S3 Object Lock with governance-mode retention to prevent deletion of event log files during the retention period, even by AWS root account holders. This satisfies regulatory requirements for immutable audit trails.

What Happens When Events Expire

When event log entries reach the end of their retention period, they are permanently deleted from the database. Deletion is performed in background batches during off-peak hours to avoid impacting workspace performance. Deleted events cannot be recovered. If you need to preserve events beyond their retention period, export them before they expire.

Immutability and Integrity

Event logs in Provisionr are designed to be tamper-evident and immutable. This is a foundational design principle, not an optional feature.

Append-Only Storage

Events are written to append-only storage. The application does not expose any API endpoint, CLI command, web interface action, or database operation to update or delete an event log entry. This is enforced at the application level and, for Scale plan customers, at the storage level with S3 Object Lock.

Cryptographic Hash Chain

Each event includes a cryptographic hash computed from its contents and references the hash of the previous event in the workspace’s event log. This creates a verifiable chain of integrity similar to a blockchain — if any event in the chain were modified, the hash chain would break, and the tampering would be detectable.

You can verify the integrity of your event log at any time by recomputing the hash chain from any starting point. The Admin CLI provides a verification command:

provisionr events verify --since "2026-01-01"

This command recomputes the hash chain for all events since the specified date and reports any integrity violations.

Storage-Level Immutability (Scale Plan)

Scale plan customers benefit from S3 Object Lock with governance-mode retention. Once an event log file is written to S3, it cannot be deleted or overwritten until the retention period expires. This provides storage-level immutability that is independent of the Provisionr application — even if the application were compromised, the S3 event log files would remain intact.

Internal Access Controls

Provisionr employees do not have routine access to customer event logs. Access to customer data requires just-in-time authorization through a controlled process, and all employee access to customer environments is itself logged in a separate internal audit trail.

Compliance Mapping

Event logging is designed to satisfy the audit trail and monitoring requirements of major compliance frameworks. The table below maps Provisionr’s event logging capabilities to specific controls.

Framework	Controls	How Event Logging Satisfies
SOC 2 (TSC)	CC6.1 (Logical Access)	Every authentication event and access change is logged with actor identity
SOC 2 (TSC)	CC7.2 (System Monitoring)	Continuous logging of all operations with error detection and alerting
SOC 2 (TSC)	CC8.1 (Change Management)	All configuration and policy changes logged with before/after values
ISO 27001	A.12.4 (Logging and Monitoring)	Comprehensive event logging with structured types and retention policies
ISO 27001	A.9.2 (User Access Management)	Every group membership change logged with the policy rule that triggered it
NIST 800-53	AU-2 (Auditable Events)	All security-relevant events are logged automatically
NIST 800-53	AU-3 (Content of Audit Records)	Events include who, what, when, where, and outcome
NIST 800-53	AU-6 (Audit Review)	Filtering, search, and export tools for reviewing audit records
NIST 800-53	AU-9 (Protection of Audit Information)	Immutable storage with cryptographic integrity verification
NIST 800-53	AU-11 (Audit Record Retention)	Configurable retention from 90 days to indefinite
HIPAA	§ 164.312(b) (Audit Controls)	Hardware, software, and procedural mechanisms to record and examine activity
HIPAA	§ 164.308(a)(1) (Security Management)	Event logs support risk analysis and security incident tracking

If you need a compliance-specific report or attestation related to event logging, contact your account team or [e-mail].

Monitoring and Alerting

Event logs are not just a passive record — they are also used to generate operational alerts and notifications.

Error Notifications

When a sync encounters errors (failed API calls, rate limits, unauthorized responses), Provisionr can notify your team through your configured notification channels. Error notifications include the event type, the affected record, the error details, and a direct link to the event log entry in your workspace.

Sync Summary Notifications

After each scheduled sync completes, Provisionr can send a summary notification showing the total number of changes made, any errors encountered, and the sync duration. This gives your team a quick daily or weekly pulse on what Provisionr is doing in your environment without needing to check the event log manually.

Webhook Notifications

Growth and Scale plan customers can configure webhook notifications that fire when specific event types occur. This allows you to build custom alerting, automation, or integration pipelines triggered by event log entries. For example, you could trigger a Slack notification when a user is removed from a critical security group, or send an event to your SIEM when an authentication failure occurs.

Performance Metrics in Event Logs

Every event log entry includes timing information that helps you understand the performance of Provisionr’s operations and your connected vendor APIs.

The event_ms field records the time spent processing the event within Provisionr (rule evaluation, database operations, etc.). The duration_ms field records the total wall-clock time for the operation, including any external API calls. The difference between duration_ms and event_ms indicates how much time was spent waiting on external vendor APIs.

These metrics are useful for:

• Identifying slow vendor API responses that are delaying your syncs
• Understanding the performance impact of adding more policies or users to your workspace
• Detecting vendor API degradation before it causes sync failures
• Planning sync frequency based on actual sync duration

Frequently Asked Questions

Can I delete event logs from my workspace? No. Event logs are immutable and cannot be deleted by any user, administrator, or Provisionr employee. This ensures the integrity of your audit trail for compliance purposes. Events are automatically removed only after your plan’s retention period expires.

What happens to event logs if I downgrade my plan? If you downgrade from Growth or Scale to Baseline, your retention period changes to 90 days. Events older than 90 days will be deleted on a rolling basis after the downgrade takes effect. We recommend exporting your event log history before downgrading.

Are event logs included in data exports when I cancel my subscription? Yes. You have 30 days after cancellation to export your data, including event logs, in JSON, CSV, or YAML format via HQ or the API.

How quickly are events available after they occur? Events are written synchronously at the time of the operation and are available for viewing and querying immediately. There is no delay between an operation completing and the event appearing in your event log.

Can Provisionr employees access my event logs? Provisionr employees do not have routine access to customer event logs. Access requires just-in-time authorization and is itself logged in a separate internal audit trail.

Do manual syncs generate event logs? Yes. Clicking the Sync button on any policy generates the same event log entries as a scheduled sync, including all membership changes, API calls, and performance metrics. There is no difference in audit coverage between manual and scheduled syncs.

How do I correlate Provisionr event logs with my vendor’s logs? Vendor API events include the request identifiers returned by the vendor in their response headers (e.g., Okta’s x-okta-request-id, Google’s request trace ID). You can use these identifiers to cross-reference a specific API call in Provisionr’s event log with the corresponding entry in your vendor’s admin console or logs.

What happens if a sync is interrupted (e.g., by a deployment or infrastructure restart)? If a sync is interrupted, all events logged before the interruption are preserved. The interrupted sync is logged with an error result, and the next scheduled sync will pick up where it left off. No events are lost due to interruption.

Can I use event logs to undo a change? Event logs record what happened but do not provide an automated undo mechanism. However, because each membership change is logged with the specific group, user, and action taken, you can use the event log to identify exactly what needs to be reversed and then perform the reversal manually or through the CLI. If a policy sync made incorrect changes, correcting the policy and running a new sync will bring memberships back to the expected state.

How do event logs work during the initial setup of a new policy? When you create a new policy and run the first sync, Provisionr evaluates all users against the policy’s rules and logs an event for each user who qualifies. If the corresponding vendor group already has members, Provisionr compares the policy’s expected membership against the group’s actual membership and logs additions, removals, and skips accordingly. The initial sync produces the same event types as subsequent syncs — there is no special “initial setup” event type.

Is there a limit on the number of events my workspace can generate? There is no hard limit on event volume. Workspaces that manage many policies across many vendors will naturally generate more events. Storage and query performance are managed by Provisionr’s infrastructure, and Scale plan customers benefit from dedicated compute resources for event log storage and retrieval.

Can I set up alerts for specific event types? Yes. Growth and Scale plan customers can configure webhook notifications triggered by specific event types or patterns. Baseline plan customers receive error notifications through their configured notification channels. See the Monitoring and Alerting section above.

---

For the complete list of event types and their descriptions, see the Event Log CLI Reference. For questions about event logging or compliance, contact [e-mail].