Logs

Updated September 7, 2026

Two features answering two different questions. System Logs is the platform’s own view of the infrastructure and runtime underneath it. Audit Logs is the record of what people did, including what they looked at. Where Tracking follows a single message and Monitoring shows current state, these two are the historical record of everything else.

The two exist for different readers. System Logs is a support surface: when something at the platform or infrastructure level misbehaves, the evidence is in the product rather than scattered across the Azure portal, so an operator, or Cerebrum City support working a ticket, can diagnose it without anyone opening a subscription. Audit Logs is an accountability surface: it answers who did this, and when, and it does not stop at changes.

Both are Grow and Enterprise capabilities. System Logs and Audit Logs belong to the managed editions. Starter deployments include neither.

Overview

System Logs and Audit Logs

Keeping them apart is deliberate. A support engineer chasing a failed adapter connection does not want to wade through sign-in records, and an assessor asking who opened a message body does not want to read stack traces. Each feature carries its own retention window, because the useful life of a runtime error and the useful life of an access record are not the same.

Feature	What it records	The question it answers	Who reads it
System Logs	Azure resource diagnostic and activity events, and the iQBus runtime’s own structured emissions.	What is the system doing, and why did it break?	Operators, and Cerebrum City support working a ticket.
Audit Logs	Every operator action, and every read of data, including a message body opened in Tracking.	Who did this, when, and what did they see?	Administrators, and whoever answers to an assessor.

Feature

System Logs

System Logs exists so that system-level and infrastructure-level support happens inside iQBus. Without it, diagnosing a throttled namespace or a failed deployment means opening the Azure portal and walking resources one at a time, which needs subscription access, portal familiarity, and a person who has both. System Logs routes what Azure emits and what the runtime emits into one place with one time range and one filter, so the same investigation is a search rather than an expedition.

It draws on two kinds of source.

Azure resource diagnostics

Everything Azure itself records about the resources iQBus runs on. The platform turns on the diagnostic-setting and audit feeds and routes them into one queryable workspace.

Source	What it captures	Why it matters
Azure SQL audit (iQBusDB, TrackingDB)	Every login, every schema change, every query execution that touches an audited table.	Database-layer access record: who connected, what changed, and which audited tables were read.
Key Vault diagnostics	Secret get / set / delete, key wrap / unwrap, certificate operations, with caller identity.	Shows that credential rotations actually happened, and that nothing outside the platform pulled a secret.
Storage account diagnostics	Blob and file read / write / delete operations with caller identity and source IP.	Relevant when message payloads are persisted to blob.
App Service logs	Process stdout / stderr, deployment events, container restarts, autoscale actions.	The first place to look when a runtime error is shaped like a platform issue, not an integration issue.
Service Bus operational logs	Namespace operations, throttling events, dead-letter actions.	Correlates throttling visible in Monitoring back to the responsible client or namespace operation.
Azure Activity log	Subscription-level changes, resource creates / deletes, role assignments, policy edits.	The change-management spine. Any “who scaled this tier?” question lands here.
Sign-in & Entra ID logs (where applicable)	Tenant sign-ins, conditional-access decisions, MFA challenges.	Authentication record below the iQBus layer.

Azure diagnostics are sourced, not generated. The platform consumes what Azure already emits, it does not invent a parallel record. That keeps the stream reconcilable: what System Logs shows can be checked against the same events in the Azure portal and they will match.

iQBus runtime events

What iQBus’s own software writes as it runs. These are structured JSON events with a fixed envelope so a single KQL query can filter across the whole platform without parsing free-form strings. Where Tracking answers what happened to this message, runtime events answer what was the runtime doing at the time.

Event class	Examples
Port lifecycle	Port started, stopped, restarted (restart is an action that cycles a port, not a third state); adapter connection opened, closed, failed; listener bound to endpoint.
Pipeline trace	Each pipeline component’s entry, exit, and outcome, without payload, distinct from the body-bearing Tracking record.
Map evaluation	Map invoked, custom function called, validation failure, transformation error.
Runtime error	Unhandled exceptions with stack, correlation ID, originating port, and the Tracking step ID they belong to.
Deployment event	NuGet package published, snapshot generated, snapshot applied, configuration applied.
Background job	trackingdb-prune, index-maintenance, snapshot-generate, secret-expiry-scan, backup-verify, entry, exit, duration, outcome.

Runtime event envelope

Field	Purpose
`timestamp`	UTC, sourced from the host’s NTP-synced clock.
`tenant`	Always present, even on single-tenant deployments, keeps the schema portable.
`application` / `port`	The configured objects the event came from, where applicable.
`tracking_id`	Correlates the line into a Tracking run when one exists.
`level`	`debug` / `info` / `warn` / `error` / `fatal`.
`event`	A stable, machine-readable event name (e.g. `port.lifecycle.started`).
`actor`	Always `system`. Operator-attributed events live in Audit Logs.

Feature

Audit Logs

The record of everything a person does in the platform. Exhaustive in coverage: if a human or a service principal did something, including simply looking at a message body, it shows up here. The audit record itself is lightweight by design, it carries the actor, the action and the target, never the payload that was viewed.

Category	Tracked actions
Identity	Sign-in, sign-out, failed sign-in, MFA challenge result, session expiry, impersonation start / end.
Data access	Message body viewed in Tracking, tracked payload opened, log record read. Reads are recorded with the same weight as changes.
Configuration	Application, port, pipeline, map, schema, variable, constant, custom function, pipeline component, create, update, delete; before / after diff on update.
Credentials	Adapter credential rotated, Key Vault secret reference changed, API key issued / revoked, certificate uploaded.
Runtime control	Port started / stopped, suspended run resumed / terminated, deployment promoted between environments.
Administration	User added / removed, role granted / revoked, RBAC policy edited, tenant setting changed.
Snapshots & retention	Snapshot generated, snapshot applied, retention window changed.
Self-audit	Audit-log read, retention-policy change on the audit record itself. Audit Logs watches itself.

Reading is an action. Most systems audit what changed and stay silent on what was seen. Audit Logs records both, so a message body opened in Tracking leaves a record naming who opened it and when. Where the data flowing through an integration is regulated, who looked at it is usually the question an assessor asks first, and it is the one an unaudited system cannot answer.

Audit Logs outlives what it records. Audit records are not owned by the objects they describe. Deleting an Application removes its artifacts, its private bus, and all of its tracking data, but the record of everything done to that Application, including the deletion itself with its actor and timestamp, stays for its retention window. Destroying the subject does not destroy the record of what was done to it.

Actor envelope

Field	Purpose
`timestamp`	UTC, sourced from the host’s NTP-synced clock.
`actor.type`	`user`, `service_principal`, or `system`.
`actor.id` / `actor.email`	The identity that performed the action.
`source_ip` / `user_agent`	Where the action originated.
`action`	Stable verb (e.g. `port.update`, `credential.rotate`, `tracking.body.view`).
`target`	The object the action ran against, fully qualified.
`before` / `after`	JSON diff for configuration changes; `null` for reads and for actions without a stateful before/after.
`outcome`	`success` / `denied` / `error`; denied actions are recorded with the same weight as successful ones.

Denied actions are first-class records. Someone probing a port they cannot edit looks identical to a benign mis-click until you read the audit record. Both attempts are written.

Storage

Retention

System Logs and Audit Logs each carry their own retention window, set independently of the other. Records stay queryable for the length of that window. The two are separated because the useful life of a runtime error is short and the useful life of an access record is not.

Changing a retention window is itself an operator action, so it is written to Audit Logs with the actor and the timestamp that made the change.

Retention windows are a deployment decision. They are agreed and set for a given deployment rather than fixed by the platform, so plan them alongside whatever record-keeping obligations apply to the data flowing through the integrations, not afterwards.

Status

In delivery

The capabilities in this section are not available today. They are designed and in delivery. Do not plan a deployment, an audit response, or a compliance programme around them. Everything described elsewhere on this page ships now on Grow and Enterprise.

Capability	What it will add
Tamper-evident storage	Append-only write guarantees and a hash-chained audit record, where each entry references the hash of the one before it, so a retroactive edit is detectable by recomputing the chain.
Archive tiering	Records ageing out of the live window into longer-term storage that stays queryable at higher latency and lower cost.
Immutable archive	A time-based immutability policy on archived records, so they cannot be deleted before the policy expires regardless of credentials.
Export	CSV, JSONL and Syslog output, and forwarding to a SIEM.
Auditor and legal-hold bundles	A signed, hash-manifested archive of a specified time range across both features, the shape outside counsel or a regulator typically asks for.
Per-role log permissions	Read and export rights scoped by platform role, including read-your-own-actions for non-administrators.
Framework control mappings	Published mappings from System Logs and Audit Logs to named SOC 2 and HIPAA controls, so an assessor can be handed the mapping rather than deriving it.

That’s Logs

System Logs for what the platform and its infrastructure are doing, Audit Logs for what people did and saw. Tracking shows what happened to a message; Monitoring shows whether the plant is healthy; these two are where you find out why it broke, and who touched it.