> For the complete documentation index, see [llms.txt](https://docs.decisionrules.io/doc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decisionrules.io/doc/space/event-logs-service-logs-and-notifications.md). # Event Logs, Service Logs and Notifications *Event Logs* show what happened to your rules — created, updated, deleted, shared. *Service Logs* show every API call made to your space. *Webhooks* notify external systems when events happen. The three work together: an API call produces a Service Log entry and one or more Event Log entries, and webhooks subscribed to those events fire as the changes are recorded. #### Finding the Audit Menu All audit data for a space is available in the *Audit* menu accessible from the Homepage via Space -> Audit.

Location of the Audit tab

The menu has two tabs: *Event Logs* (changes to your rules) and *Service Logs* (API calls). Both tabs share the same toolbar — search box, filters, date range, and pagination controls. ### Event Logs Each row in Event Logs records one change to a rule. You'll see when it happened, what kind of change, which rule was affected, and who made the change.

Overview of Event Logs

#### Event types The events recorded for rules are: * **Created** * A new rule was created * **Updated** * An existing rule was modified * **Deleted** * A rule was permanently removed * **Shared** * A rule was shared into another space * **Unshared** * A rule was removed from a space it was shared into #### Initiated by The *Initiated by* column shows who made the change. Two formats are possible: * **User email** — the change was made by someone signed in via the web app * **Truncated API key** — the change was made by an integration using a management API key {% hint style="info" %} For security, only a truncated form of the API key appears in audit data. The full key value never leaves the backend, even in audit logs. {% endhint %} #### Cross-space events When a rule is shared between spaces, changes to that rule affect every space that has access to it. A small ↗ icon next to the action indicates a cross-space event — meaning the change was made from a different space. Open the row's detail drawer to see which space the change originated from.

Event Log - Rule Updated performed in a different Space

### Service Logs Each row in Service Logs records one API call to your space. You'll see the HTTP method, the URL path, the response status code, and when the call happened.
Failed authentication attempts are also recorded — useful for spotting unexpected access patterns. #### Status code groups Status codes are grouped into colored bands: * 2xx — successful requests * 4xx — client errors (bad requests, unauthorized, not found) * 5xx — server errors #### Request body Each Service Log entry captures the body sent with the request. Large fields are truncated to keep storage manageable: nested objects are collapsed to `[object]`, large arrays are collapsed to `[array]`, and strings longer than 1KB are cut with a `…[truncated]` marker. This means you can see *what* was sent without storing megabytes of decision-table data on every request. ### How Event Logs and Service Logs Connect Every Event Log entry has a parent Service Log. One Service Log can have many child Events. Why? One API call can change many things. Deleting a folder with five rules is one DELETE request (one Service Log row) that produces five Deleted events (five Event Log rows). All of them share the same *correlation ID*. You can navigate between the two views: * From an Event or Service Log entry, click **Inspect Service Log / Inspect Event Log(s)** to jump to the API call that produced it
{% hint style="info" %} For cross-space events, the related Service Log lives in the originating space — you can see the event itself but not navigate to its API call from a receiving space. {% endhint %} ### Correlation IDs A correlation ID is a unique identifier shared by every record produced by one API call. Use it to: * Search either tab to find every record related to one operation * Trace requests across systems — pass your own correlation ID by sending an `x-correlation-id` HTTP header on your API call, and the same value will appear in both Event Logs and Service Logs When you provide your own correlation ID, the API response includes it back in the `x-correlation-id` response header so your integration can capture it. ### Filtering and Searching The toolbar above each list supports: * **Search** — matches against rule names, user emails, API keys, URL paths, and rule IDs (depending on which tab you're in) * **Filters** — narrow the list by event action, resource type, HTTP method, status code, or correlation ID * **Date range** — defaults to the last 24 hours; expand to whatever window you need All filters combine and can be cleared with one click. #### Pagination Results are paginated. Use the page-size selector to switch between 10 and 20 rows per page, and the arrows to move forward and backward. The "x of y" counter shows your position; counts above 10,000 display as "10,000+". ### Data Retention Audit data is retained for 90 days. After that, both Event Logs and Service Logs entries are automatically deleted. The retention window applies equally to both, so an Event and its parent Service Log expire together. ### Webhooks Webhooks notify external systems when events happen in your space. They're configured per space and fire as events are recorded. {% hint style="info" %} Webhooks are configured separately in the *Webhooks* menu. See [Webhooks](https://docs.decisionrules.io/doc/space/webhooks) for full setup details. {% endhint %} #### Subscribing to events When you create a webhook, you choose which events to subscribe to. Events are grouped by resource type: * **Rule events** — Created, Updated, Deleted, Version Created * **Job events** — Completed, Canceled, Error For rule events specifically, you can also filter by rule status: * **Published only** — only fire for changes to published rules * **Pending only** — only fire for changes to pending rules * **Both** — fire for any rule status change Leaving both checkboxes ticked is the default and gives you all rule events.
#### Webhook delivery Each webhook POST includes signed headers your endpoint can use to verify authenticity: * `X-Webhook-Signature` — HMAC-SHA256 of the payload, signed with your webhook secret * `X-Webhook-Timestamp` — when DecisionRules sent the notification * `X-Webhook-Delivery-Attempt` — which retry attempt this is (0 = first try) If delivery fails (timeout, 5xx response, or rate limiting), DecisionRules retries up to 3 times with exponential backoff (1s, 2s, 4s). Other 4xx responses are not retried — they indicate a permanent problem with the request shape and retrying won't help. Webhook delivery is fire-and-forget: a slow or failing webhook never delays the original API call's response to the user. #### Payload shape Each webhook POST includes: * `eventType` — the combined event identifier (e.g. `RULE.UPDATED`) * `entityType` and `action` — the same information split into separate fields * `data` — the resource-specific payload * `metadata.timestamp` — when the notification was sent * `metadata.spaceId` — the space the event belongs to * `metadata.correlationId` — for cross-system tracing * `metadata.requestLogId` — references the parent Service Log entry For cross-space events, the payload also identifies the originating space so your system can show appropriate context. #### When a webhook will not fire A subscribed webhook will not fire if: * The webhook is inactive (toggle off) * The event type is not in the webhook's subscription list * The rule-status filter excludes the event (rule events only) * The underlying database write failed — DecisionRules will not notify about something that wasn't actually recorded --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.decisionrules.io/doc/space/event-logs-service-logs-and-notifications.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.