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

# Runs, Logs, and Audit

> Use Monitoring as the operational truth for Platinur runtime activity.

Monitoring answers four questions: is the workspace healthy, what ran, what still needs attention, and who changed what.

## The 7-day pulse

The pulse counts the active environment's last seven days: total runs, failures, publishes, and
deliveries. **Publishes** are release/production-refresh executions—not Git commits or Assistant
proposals. Switch Staging/Production to change the environment represented; counts do not combine
the two environments.

## The sections

**Overview · Runs · Issues · Audit.** Opening Monitoring lands on Overview.

* **Overview** — overall state, active work, unresolved issues, seven-day counts, and the latest successful run in each pipeline stage.
* **Runs** — the complete execution ledger. Filter by Running, Failed, Succeeded, Sources, dbt, Dashboards, Deliveries, or Publishes.
* **Issues** — unresolved failures, runs stalled for more than 30 minutes, and schema drift. A newer success for the same subject resolves an older failure.
* **Audit** — who did what: settings changes, source changes, proposal actions, schedule updates, access-control events.

Each run records status, environment, timestamps, events, and logs. A newer successful execution
for the same environment, run kind, and subject resolves its older failure; a success in Staging
does not resolve a Production issue.

Successful and failed dbt, source, dashboard, delivery, and production publish executions all remain in Monitoring. Subject pages retain their controls and may show the latest result, while ordinary edits and schedule saves stay in Audit.

## Logs

Open a run to inspect its event stream. Running jobs update as they progress, and completed jobs remain available for review. For a failed connection, the log includes the error category, the advice, and the non-secret connection signals (host, port, base URL, driver) — credentials are never shown.

## Schema drift

Monitoring watches for **schema drift**: an hourly check (plus an on-demand **Check** button)
compares your raw source schemas against the baseline captured at the last build. Drift —
a dropped column, a type change — is named precisely, and failed runs caused by it carry a
**Repair with Assistant** button that opens a guided repair. See
[Failure Recovery](/operations/failure-recovery).

## Audit

Audit entries record user-visible product actions such as settings changes, source changes, proposal actions, schedule updates, and access-control events.

## Failure triage

Use Monitoring to identify which system failed, what action caused it, and whether the failure should be retried, repaired through Assistant, or escalated to an operator. When escalating, attach a **support bundle** from the separate **Support** sidebar page—a redacted diagnostics archive with status, configuration, recent runs, and schema drift, never secrets.