# Observe · Neural Inverse Govern > Built-in metrics and log groups for every Govern service, your own metrics and logs, search, live tail, alarms with notification channels, and a built-in telemetry pipeline with hot and cold tiers, per account or per project. Source: https://neuralinverse.com/govern/observe/ --- ![](/photos/facility.jpg) [Neural Inverse Govern / Observe](https://neuralinverse.com/govern/) # Metrics, logs and alarms for your AI tools and services, without an external monitoring stack. Built-in metrics and log groups for every Govern service, your own metrics and logs, search, live tail, alarms with notification channels, and a built-in telemetry pipeline with hot and cold tiers, per account or per project. Metrics 1-minute resolution, percentiles on the server Logs Retention per group, search and live tail Alarms Threshold, anomaly detection, composite Telemetry Hot PostgreSQL hours, cold sealed Parquet Dependencies PostgreSQL and object storage or a directory Overview Observe holds the metrics and logs of your account and its projects. Every Govern service publishes metrics and logs without setup, applications publish their own, and the server computes statistics, searches logs and evaluates alarms, so the console only renders answers. The built-in telemetry pipeline carries agent and service events from the bridge to hourly PostgreSQL partitions and sealed Parquet files, and Observe searches both tiers as one log group. [What it does ↓](https://neuralinverse.com/#capabilities)[How it works ↓](https://neuralinverse.com/#workflow)[Enforced and recorded ↓](https://neuralinverse.com/#enforcement)[Where it runs ↓](https://neuralinverse.com/#where)[Get started ↓](https://neuralinverse.com/#get-started) What it does ## What Observe provides. Metrics, logs, alarms and telemetry, as they run today. - **Built-in service metrics:** Metrics every service emits with no setup: gateway, agents, policy, workspaces, sandboxes, MCP, vault, identity, approvals, skills, harness packs and AI health. - **Custom metrics:** Publish metrics at 1-minute resolution per account or per project and read them with server-side statistics, percentiles, trimmed means and interquartile means included. - **Usage and personal metrics:** Hourly samples of each counted service quota for quota pressure, and a view where every member reads their own usage, cost and sign-in failures. - **Log groups and retention:** Create log groups for the account or a project and set retention from one day to ten years; data past retention is dropped by day. - **Service logs without setup:** Gateway calls and content, agent actions and policy decisions, access checks and vault access, MCP calls, sandbox output, workspace builds and sign-ins, readable as log groups. - **Log ingest and search:** Write log events through a bounded buffer, search a group with filter patterns, or page through one stream. - **Metric filters:** Turn matching log events into custom metrics, evaluated after each flush. - **Live tail:** Stream new events of chosen log groups as they are written. - **Signed export:** Export a group's events as signed NDJSON to the account archive or your own bucket in the same region. Aged-out data goes to an HMAC-signed archive on object storage with Object Lock, or local disk. - **Metric and composite alarms:** Threshold alarms on one metric, and composite alarms over other alarms with AND, OR and NOT. Alarms are evaluated on the server every minute and show the datapoints that decided their state. - **Anomaly detection:** Bands learnt per hour of the week from 14 days of data; an alarm on a model still training reports insufficient data rather than guessing. - **Notification channels:** Email, signed webhooks, Slack and PagerDuty. Channel secrets are write-only and sealed under the account's key; deliveries are retried for up to 24 hours and every outcome is recorded. - **Telemetry pipeline:** Agent and service events land in a write-ahead log on the bridge, acknowledged after fsync, then in hourly PostgreSQL partitions without duplicates, then in sealed, verified Parquet files. - **Telemetry search and status:** Search the pipeline's events across both tiers as one log group, redacted by DLP, with status that says Healthy, Delayed or Not receiving and why. - **Back-pressure, never a silent drop:** A full disk or an organisation over its rate gets a refusal with a retry time; records ingest refuses go to a dead-letter log that can be replayed. - **Telemetry retention:** Set how long the account's archived telemetry is kept, from one day to your maximum, and keep telemetry in a dedicated or sharded database if you need to. How it works ## How an alarm reaches the on-call engineer. 1. Publish A service or application publishes a metric, or a metric filter derives one from logs. 2. Evaluate The server evaluates every alarm each minute against its threshold, band or rule. 3. Change state A new state queues one delivery per channel in the same transaction. 4. Deliver One replica sends it, retrying with backoff for up to 24 hours. 5. Record The transition and the delivery outcome are in the alarm history and the audit log. Who uses it ## Built for every role that answers for AI. - **Site reliability engineers:** Set alarms and channels, tail logs and watch the services they run. - **Platform engineers:** Run the telemetry pipeline, choose its cold store and set retention. - **Application teams:** Publish their own metrics and logs per project and read them without account-wide access. - **Security teams:** Search agent actions, policy decisions and vault access, and export them signed. Enforced and recorded ## Your data stays readable only to those who may read it. Reads, writes and deliveries are checked on the server. Enforced - **Scope:** A project's metrics, logs and alarms are read and written with rights on that project; account data needs rights on the account. - **Alarms on readable data:** Creating an alarm needs read access to the data it watches, so nobody learns a metric's state through an alarm. - **Channel secrets:** Webhook URLs, keys and signing secrets are sealed and never returned; without key management they are refused. - **Outbound calls:** Notifications refuse private, loopback and link-local addresses and follow no redirects. Recorded - **Configuration:** Every alarm, anomaly detector and notification channel change, in the transaction of the change. - **Deliveries:** Each delivered, failed or suppressed notification. - **Exports:** Exports are signed so you can check them, and cold archive files carry an HMAC. Where it runs ## Wherever Govern runs. [Deployment options](https://neuralinverse.com/deployment/) - **Self-hosted:** Metrics, logs and alarms run in the Govern server; the telemetry pipeline is off until you turn it on. - **Air-gapped:** The telemetry pipeline's cold tier and the log archive can use a local directory instead of a bucket. Kafka is not needed. - **Hosted by us:** Data stays in the region that serves your account; exports go only to its archive or your bucket in the same region. Get started ## Set it up with the documentation. - [Telemetry pipeline](https://neuralinverse.com/docs/deploy/telemetry-pipeline/) - [Monitoring and self-healing](https://neuralinverse.com/docs/deploy/monitoring/) - [Exports and signed packages](https://neuralinverse.com/docs/evidence/exports/) What's next ## Being built now. These are in development and not part of the product today. - **Dashboards and metric math:** Saved dashboards per account or project, shared with roles, and metric math in queries and alarms. - **Log queries:** A query language over log groups, run on the server. - **Traces:** An OpenTelemetry receiver whose trace IDs join spans, gateway calls, logs and audit records. - **Event rules:** Routing platform events to targets, with retries, a dead-letter view and replay. - **More alarm actions:** Approval requests, kill switches and budget stops as alarm actions. - **Organisation-wide monitoring:** One monitoring account that reads every member account's metrics, logs and alarms. Related [Platform operations → Self-healing, admission control, health probes, status page, SLA tracking, feature flags and signed alerts.](https://neuralinverse.com/govern/operations/)[Audit and evidence → A hash-chained audit log you can verify offline, and evidence toward your frameworks.](https://neuralinverse.com/govern/audit/)[AI Gateway → Approved models, DLP, guardrails, budgets and rate limits for every model request.](https://neuralinverse.com/govern/ai-gateway/) ![](/photos/team.jpg) ## Talk to our team. Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation. [Request access](https://neuralinverse.com/contact/?topic=access)[Contact us](https://neuralinverse.com/contact/)