Documentation / Administration

Auditing & Telemetry

A full in-tenant audit trail of runs, configuration changes, and access — with complete failure tracebacks and before/after snapshots — plus opt-in, per-tenant telemetry that carries only aggregated error and usage counts, never your data, with retention under your control.

Nexus records what happens inside your instance — every data read and write, pipeline run, configuration change, and AI call — and keeps that record where you control it. Separately, it can send Stingray a narrow, aggregated usage signal, but only if an administrator turns it on. This page is for tenant administrators and security owners who need to answer "who did what, when, what changed, and what did it cost" — and to know exactly what, if anything, leaves the tenant.

Everything stays in your tenant

Nexus runs entirely in your own Azure subscription, so its records do too. The audit and telemetry data sits in your own per-tenant PostgreSQL database alongside your reports and pipeline definitions. Stingray does not see your query results, file contents, credentials, or business data. The only thing that can ever leave is the optional, aggregated cost-and-usage signal described under Opt-in telemetry — and only after you enable it.

The audit trail

Every meaningful action produces a durable, attributable event. Because Nexus authenticates every principal against Entra ID and checks every action through RBAC, each record carries the identity that caused it.

Run records

Each pipeline and report run is captured as a run record with its status, timing, triggering identity, and — for privileged runs — which execution role it assumed. Individual operations within a run emit structured telemetry events you can inspect:

Event kind	What it captures
`adapter_call`	A read or write against a connected data source (your databases, NetSuite, Monday, and other bridges)
`llm_call`	An AI request routed through Nexus, including token usage
`cost_anomaly`	A flagged spike in spend for a pipeline (see below)

Because runs carry the triggering user or application identity and are scoped by RBAC, the trail answers governance questions directly: which user ran a report, which application wrote to a system, which integration an AI action touched, and under which role.

Complete failure tracebacks

When a run fails, Nexus persists the complete exception traceback with the run — not a truncated one-line error. An operator can open a failed run and see exactly where and why it broke, with structured logs alongside, without needing to reproduce it or attach a debugger. This is retained per run, so a failure that happened last week is as inspectable as one from an hour ago.

Configuration-change auditing

Changes to what Nexus is, not just what it did, are recorded too:

Authored definitions (pipelines, reports, Sites, skills) are versioned in a per-tenant git repository with full commit history, diffs, and restore — a complete, queryable log of every edit and who made it. See Version Control.
Before/after snapshots are captured around sensitive changes, so a configuration edit shows both its prior and new state, not merely that "something changed."
Access and approval events — role and grant changes, and the approval workflow that gates sensitive runs — are recorded with the acting identity, giving you an audit of who granted whom what, and who approved a dispatch.

Cost telemetry and rollups

Nexus assigns each operation a cost figure in normalized cost units derived from adapter work and AI token consumption. As runs complete, a background accumulator aggregates events into rolling totals at three levels — per run, per pipeline (lifetime), and per tenant (lifetime).

Cost lineage across pipelines

When one pipeline invokes another, Nexus tracks the relationship so child cost rolls up to its parent. A top-level, user-triggered run shows both its own cost and the recursive total of everything it set in motion — answering "this one user action cost how much across every pipeline it triggered" with no manual reconciliation.

Top-level run  (triggered by a user)
  ├─ own cost ............ 12.4 units
  └─ descendant cost ..... 38.1 units   ← all child pipelines, recursively
     ├─ enrichment pipeline ... 9.0
     ├─ sync pipeline ........ 21.6
     └─ notify pipeline ...... 7.5

Anomaly detection

Nexus continuously compares a pipeline's recent spend against its longer-term baseline. When short-term median cost rises sharply above the 30-day median — and there is enough history to make the comparison meaningful — it records a cost_anomaly event and logs a warning. A floor on the baseline prevents false alarms on pipelines that are cheap in absolute terms.

Admin reporting

Administrators with the cost-reporting permission can query rollups through the admin API. These endpoints read aggregated data only; they never modify records.

Endpoint	Answers
`GET /api/admin/costs/summary?period=7d`	Per-pipeline cost over a window (e.g. `24h`, `7d`, up to `365d`)
`GET /api/admin/costs/adapter-breakdown?period=7d`	Which connected integration is most expensive
`GET /api/admin/costs/anomalies`	Historical anomalies plus a live re-check of currently anomalous pipelines

The adapter breakdown is the fastest way to see where spend concentrates — for example whether a particular ERP or AI integration dominates monthly usage.

Opt-in telemetry

Sending any signal beyond your tenant is opt-in and administrator-controlled. You decide whether Nexus reports aggregated cost and usage back to the Stingray control plane for billing and support.

Off means nothing leaves. When telemetry is off, no signal is sent — the audit and cost data stay entirely in your database.
On sends only aggregates. When enabled, only aggregated metrics leave: counts, totals, and breakdowns — for example run counts, total cost units, an adapter-level breakdown, and an anomaly count, summarized per tenant per month. Your underlying data, query results, file contents, and credentials are never included. There is no field in the telemetry payload that carries a row, a value, or a secret.
Per-tenant. The toggle is a tenant-level setting an administrator owns, not a global default imposed on you.

When enabled, the control plane keeps a per-tenant monthly summary (total cost units for the month, lifetime totals, run count, adapter breakdown, anomaly count) to drive marketplace billing and let support reason about usage without ever touching your data.

Retention is under your control

Because audit and telemetry records live in your per-tenant PostgreSQL database, retention is governed by you, not by Stingray. You keep records as long as your compliance program requires, apply your own database backup and archival policy, and prune on your own schedule. Nexus does not impose an external retention window on your in-tenant records, and it cannot reach in to delete them. Point-in-time restore on the Postgres Flexible Server applies to this data exactly as it does to the rest of your Nexus state.

Privacy summary

Data content stays in your tenant. Audit, cost, and run records live in your own database; result sets, file contents, and credentials never leave.
Failures are fully inspectable in-tenant. Complete tracebacks and structured logs are retained per run.
External reporting is opt-in and aggregate-only. Telemetry to Stingray is off until an administrator enables it, and then carries only counts and totals — never your data.
Access is governed. Cost and audit endpoints require an administrative permission and respect your existing RBAC.
Retention is yours. Records live in your database on your retention and backup policy.