> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lumos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Monitoring and Observability in Lumos

## Overview

This article covers two related topics:

* **Part 1:** What Lumos produces at the end of a User Access Review (UAR) campaign, and how that evidence holds up for an auditor.
* **Part 2:** A recommended set of observability standards, including a health-check dashboard you can build in Lumos. These standards let your team monitor the platform continuously, not only when something breaks.

## Part 1: Audit logs and reporting at campaign end

### What campaign end means in Lumos

A campaign can't be completed until every application in scope reaches a completed state. Each in-scope application moves through preparation, reviewer assignment, and in progress, and then to completed or waiting for manual action.

Lumos blocks the **"Complete Review"** action while any line item in any in-scope application has no decision recorded. A completed campaign therefore always has 100 percent decision coverage.

When the campaign is completed, Lumos:

* Stamps a completion timestamp on the campaign.
* Records a **Completed Review** event with the actor who completed it.
* Finalizes the auditor report.
* Prepares the next campaign in the series from the recurrence settings, if the campaign is set to recur.

### The auditor report package

Completing a campaign produces two reports. Lumos generates both from a point-in-time snapshot of the review data, not from live data. The report reflects what the Reviewer saw and decided at the time of the review, not what the entitlement looks like today. This is what makes the report defensible in an audit.

#### PDF auditor report

The PDF auditor report is the narrative evidence package.

* **Cover page:** the campaign name, your company name, the date the campaign was created and who created it, and the date the report was generated and who generated it.
* **Application list:** every reviewed application.
* **Application summary page:** for each application, whether the review covered accounts or permissions, the total number reviewed, and the counts rejected, modified, and accepted. The page also shows the timestamp of the data sync the review was built from, and the complete list of Reviewers.
* **Scope filters:** if an application was scoped instead of reviewed in full, the applied scope filters are printed with the summary. An auditor can see exactly which population was in and out of scope.
* **Detail sections:** a results breakdown table per application, an evidence section with any attachments and notes Reviewers uploaded, a permissions section, and a separation of duties section that lists any rule violations found during the review.

#### CSV report

The CSV report is the line-level export. Most audit teams work from it because it can be filtered. Every reviewed line item becomes a row, with these columns:

* The application and the review type
* The account holder's name and email, account source, title, and employee status
* The provisioned date, last login, last activity, and final account status
* The entitlements or roles held, with descriptions for account reviews, and a permission description and permission tags column for permission reviews
* Any separation of duties rule violation
* The Reviewer who made the decision, the date of the decision, the decision itself, and the originally assigned Reviewer
* The notes and removal method, any linked service ticket, the decision reason, and modification instructions
* The account's external identifier in the source system

Where AI assistance was enabled, the AI suggestion, category, and insight appear as their own columns. An auditor can see the recommendation and the human decision side by side.

You can download both reports from the campaign in Lumos. Lumos records each report download, so there is a record of who pulled the evidence and when.

**Note:** Keep these two points in mind:

* You can generate reports before a campaign is finished. Lumos marks those reports as incomplete, so a mid-campaign export can't be mistaken for final evidence.
* On very large campaigns, the PDF can exceed a practical page count. In that case, Lumos skips the PDF and the CSV remains the complete record. If you expect campaigns at that scale, plan on the CSV as your primary evidence file. Contact your Lumos CSM to confirm your threshold before your first audit cycle.

### The activity log as the underlying audit trail

The reports summarize decisions. The activity log is the immutable event trail behind them. An auditor uses it to reconstruct a sequence of events instead of reading a summary.

Lumos records a timestamped event, attributed to an actor, for almost every meaningful action in the review lifecycle:

* Campaign creation, scope changes, and applications added or removed
* Reviewer assignment and notification, reminders and escalations sent, and delegation or reassignment of a Reviewer
* Each approve, reject, and modify decision, and decisions that were later removed or changed
* Notes added, evidence uploaded, and service tickets created for remediation
* Access removed, manual removals recorded by an administrator, and removal failures
* Per-application completion and campaign completion

Permission-level reviews have their own parallel set of events, so entitlement decisions are distinct from account decisions in the trail.

Each event includes the event type, a readable label, the outcome, the actor, the targets, the start time, and event-specific metadata. The record states whether the actor was a person or Lumos acting automatically. Auditors typically ask for this field when a review includes automated decisions.

Administrators open the log on the **Activity Log** page in Lumos. You can filter it by actor, application, event name, status, target user, review name, and time range, and export the filtered view to CSV. A filtered export is usually the fastest way to answer a narrow auditor request. For example, you can export every rejection and every later removal for one application in one quarter.

### Programmatic access

To pull this evidence into your own GRC tooling instead of downloading it manually, use the Lumos API. Both objects are available. See [Where to read more](#where-to-read-more) for the documentation pages.

* `GET /activity_logs` returns activity events, with `since` and `until` date filters and standard pagination. Each record includes the event type, label, outcome, targets, actor, start time, and event metadata. See [Get Activity Logs](/reference/getactivitylogs-1) in the Lumos API reference.
* `GET /access_reviews` returns your campaigns with their status, how they were created, owner and creator, deadline, start time, completion time, and attached applications. See [List Access Reviews](/reference/listaccessreviews) in the Lumos API reference.

The same API also covers individual campaigns, campaign creation, updates, and application scoping. Use it to drive campaign creation from your own schedule if you prefer that to Lumos recurrence.

### Streaming events to your security stack

For continuous monitoring instead of periodic pulls, Lumos can stream activity events flagged for security export as they happen. There are three delivery options:

* A SIEM platform integration, configured as an application in Lumos
* An outbound webhook to an endpoint you control
* An S3 bucket that you own, which Lumos writes to using a role you grant with an external ID

The S3 option is usually the best fit for a team that already stores identity telemetry in its own data platform. It avoids a dependency on a per-event webhook.

The exported events include review events such as campaign completion. You can alert on campaign milestones in your own tooling without polling Lumos.

### Remediation evidence

Most audit findings on Access Reviews are not about the decision. They are about proving the decision was carried out. Lumos treats remediation as part of the same record, not as a separate process.

* **Automatic removal:** When a Reviewer rejects access, Lumos can revoke it automatically where the integration supports write operations. The revocation attempt, its success, and its failure are separate logged events, so a failed revocation is visible.
* **Manual removal:** Where Lumos can't write to an application, the line item waits for manual action. Lumos notifies the assigned Remover and sends reminders as the deadline approaches. The administrator records the manual removal in Lumos, which creates a **manually removed** event attributed to them.
* **Ticketed removal:** With a service management integration, a ticket can be raised for the removal. The ticket reference appears on the line item and in the CSV export, which links the review decision to the ticket that fulfilled it.

Together, the CSV report's final account status, notes, and removal method columns, and the activity log's removal events, answer the two questions auditors ask: was the access removed, and when and by whom.

### Plan for changes after completion

A completed campaign is a point-in-time snapshot, so the report doesn't reflect access changes made after completion. That is correct for evidence. However, if a rejected line item is remediated after the campaign closes, the remediation appears in the activity log, not in the report.

For SOX-style testing, close the campaign only after remediation is complete. Alternatively, pair the report with an activity log export that covers the remediation window. Your Lumos CSM can help you choose the pattern that fits your control language.

## Part 2: Observability standards and a health-check dashboard

The goal is that a data problem in a connected system never reaches a Reviewer as a bad review population, and never reaches an auditor as an unexplained gap. Lumos provides five layers. Together they cover connection health, sync correctness, data freshness, and campaign progress.

### Layer 1: Connection health per integration

Every connected application in Lumos has a connection health indicator: a connected badge on the application's **Integrations** tab. The badge shows whether Lumos can currently authenticate to and reach the source system.

Connection health is separate from sync outcome. A connection can be healthy while the most recent sync failed for a data reason. Read the badge and the sync result together; don't treat the badge alone as an all-clear.

When a credential or scope problem breaks a connection, Lumos notifies domain administrators by email and Slack. The notification names the application, quotes the error, and links to the **Integrations** tab. If you run on-premises agents, Lumos sends a separate administrator notification when an agent disconnects. Confirm which team members hold the administrator role that receives these notifications, because this is the alert path that matters most in practice.

### Layer 2: Sync visibility per run

Sync Visibility shows each integration's syncs run by run. Open it from the application's **Integrations** tab. For each run, it shows:

* The stages the sync moved through: data acquisition, data transformation, data installation, and coalescing
* How long each stage took
* How many records each stage produced

You can group results by entity type (accounts, identities, entitlements, associations) or by pipeline stage. Runs in progress show a live indicator with elapsed time.

Use Sync Visibility to answer two questions: did this sync finish, and where did the record count change unexpectedly?

Sync Visibility has two limits. It covers the last seven days, and the API doesn't expose per-run sync detail. This layer is a console workflow; you can't pull it into your own dashboards yet.

### Layer 3: Circuit breakers

Circuit breakers stop an anomalous sync before Lumos installs the data. They protect you from a truncated or malformed source response that could cause unintended deprovisioning or a wrong review population.

Four rules evaluate every full sync by default:

| Rule | Trips when |
| - | - |
| Mass account deactivation | Half or more of active accounts are reported as deactivated |
| Mass account absence | Half or more of active accounts are missing from the response |
| Empty account response | Zero accounts are returned |
| Mass identity deactivation | Half or more of active identities move to terminated after coalescing |

The ratio rules require a minimum sample size before they evaluate, so small applications don't trip them by accident.

When a rule trips, the sync stops before installation and nothing in Lumos changes. The blocked run appears on the application's **Integrations** tab with the expected value, the actual value, and the threshold that was crossed.

Lumos records every change to a rule or threshold in the activity log, with the actor, timestamp, reason, and before and after values. Your circuit breaker configuration is auditable.

To resolve a tripped rule, do one of the following:

* Wait for the source to be corrected, then sync again.
* If the change was legitimate, raise the threshold or disable that rule for the application, then run the sync again.

### Layer 4: A health-check dashboard you own

Lumos includes customizable dashboards. Use them to build the one view your team checks each morning.

The application-level fields most relevant to platform health are:

* The last finished sync timestamp
* The last sync state
* A derived data freshness indicator
* Last known activity age for accounts

A useful starting layout has four tiles:

* **Integration health:** A table of all applications with the last sync state and last finished sync timestamp, filtered to failures and sorted oldest first. This is your daily triage list.
* **Data freshness:** A table of applications where the freshness indicator is false. It shows the applications whose data is too old to trust as a review population.
* **Review readiness:** Counts of terminated user accounts, partially offboarded users, dormant privileged accounts, and unmatched accounts, each filtered to applications with fresh data. The freshness filter matters: an unfiltered count mixes real findings with stale-data artifacts, and teams end up chasing false positives.
* **Campaign progress:** Complete and incomplete counts for active campaigns against their deadlines, reviewed and rejected volumes over time, and rejections by application.

**Note:** Keep these field-level details in mind:

* The last finished sync timestamp is the completion time of the last successful full sync, not the last attempt. An application that has failed for weeks shows an old but valid timestamp instead of an error. Always pair it with the last sync state.
* The dashboard field list doesn't include a last attempted sync timestamp. To see when Lumos last tried to sync, use Sync Visibility.

### Layer 5: Continuous monitoring outside Lumos

For alerting, use the activity log stream described in Part 1. Build alerts on these events:

* Integration errors
* Removal failures
* Campaign auto-launch blocked events. Lumos refuses to auto-launch a recurring campaign on stale or incomplete source data, and sends both a notification and an event.
* Campaign completion

Streaming these events into your SIEM lets you page on identity governance failures the same way as the rest of your infrastructure.

### Recommended cadence

* **Daily:** Check the integration health and data freshness tiles. Assign an owner to anything that has been failing for more than 24 hours.
* **Weekly:** In Sync Visibility, review blocked or circuit-broken runs for applications in your next campaign's scope. Confirm that the administrator notification recipients are still correct.
* **Monthly:** Review dormant privileged accounts, partially offboarded users, and unmatched accounts, filtered to fresh data. Confirm that circuit breaker thresholds still match expected business changes.
* **Before each campaign launch:** Confirm that every in-scope application has a recent successful full sync and a true freshness indicator. This check prevents the most expensive failure: a Reviewer certifying a population that was already wrong.
* **At each campaign close:** Download both reports, export the activity log for the campaign window, and confirm that every rejection has a matching removal event or a recorded manual removal.

## Where to read more

* [Scoping Your Access Review](/kb/access-reviews/preparing-and-completing-an-access-review/scoping-your-access-review)
* [Reviewing User Account Access In Lumos](/kb/access-reviews/preparing-and-completing-an-access-review/reviewing-user-access-in-lumos)
* [Get Started with Agentic Access Reviews](/kb/access-reviews/agentic-access-reviews-with-ai-driven-decisions)
* [Sync Visibility](/kb/ui-ux/sync-visibility)
* [Sync Circuit Breakers](/kb/ui-ux/sync-circuit-breakers)
* [Get Started with Customizable Dashboards](/kb/analytics/get-started-with-customizable-dashboards)
* [Incremental (Delta) Syncs: Overview and How They Work](/kb/integrations-3/reference-1/incremental-delta-syncs-overview-and-how-they-work)
* [Activity Logs API reference](/reference/getactivitylogs-1)
* [Access Reviews API reference](/reference/listaccessreviews)