Observability

When your software runs inside customer clouds, the usual self-hosting playbook breaks. There are no shared dashboards, no central log storage, and no way to ask "is this customer healthy?" without a support ticket. Alien is built so you can answer that question without leaving your control plane.

Observability in Alien covers three signal families across every deployment:

• Health and lifecycle — release version, platform, region, deployment status.
• Application telemetry — logs, metrics, and traces produced by your code.
• Runtime signals — container health, HTTP traffic, queue depth, and other operational metrics gathered by Alien's data plane.

All three are correlated by deployment, so when something looks off you can move from "all deployments" down to "this customer, this release" without piecing it together by hand.

Deployment health

The manager already knows about every deployment, the release each is running, the cloud and region it's pinned to, and when it last checked in. That state is exposed on the dashboard and through the manager API, so support and engineering teams can:

• See which customer environments are healthy, stale, updating, or pinned to an older release.
• Spot deployments that haven't picked up their channel's current release.
• Trigger pinned rollbacks for one deployment or all of them — see Releases.

Application telemetry

Inside customer environments your code produces normal logs, metrics, and traces. Alien forwards those signals out of the customer cloud over OpenTelemetry-compatible pipelines.

You wire the destination once in the manager configuration — your existing observability backend. Every active deployment automatically tags telemetry with deployment, release, resource, and runtime metadata.

See Self-Hosting → Configuration for exporter settings and Structured log severity for the optional stdout/stderr severity parser.

Captured log bodies

Alien removes the container runtime's framing and trailing record delimiter before exporting an application log. It does not replace a structured log with its message, msg, or another nested field. The application payload remains the log body, while severity and runtime context travel as log metadata.

Terminal-oriented fallback processing may remove ANSI escape sequences and control characters when inspecting unstructured output for severity. Applications should emit structured JSON or native OpenTelemetry logs when formatting has semantic meaning.

Runtime signals

Alien's data plane produces a small set of useful signals out of the box:

• Container and replica health, restarts, and last error.
• HTTP-level metrics for ingress-facing containers.
• Queue depth and consumer lag for managed queues.
• Storage and KV usage where the cloud service exposes it.

These travel through the same telemetry pipeline as application data and arrive tagged with the same deployment context.

Operational, not customer data

Observability data is deliberately scoped to runtime, infrastructure, and product health rather than the customer's application data. If you need to inspect customer-side data on demand, use a remote command, which runs inside the customer environment and leaves an audit trail.

What's next