Observability
Putnami services are observable by construction: the runtime emits structured logs, metrics, and traces by default, in the same shape locally, in preview, and in production. Debugging starts from system state, not guesswork.
Telemetry is exported over OTLP. The platform provisions a workspace collector that exports to that workspace's runtime project and makes the signals queryable through the same workspace boundary.
The shape
| Signal | Emitted by default |
|---|---|
| Logs | structured, correlated to a request and revision |
| Metrics | runtime and request metrics over OTLP |
| Traces | per-request spans over OTLP |
Because every running revision is attributable to a commit, a signal can be traced back to the exact code that produced it.
Query your service
| Want to… | Do this |
|---|---|
| Query recent errors | putnami cloud logs <app> --since 1h --level error |
| Live-tail logs | putnami cloud logs <app> --follow --output=jsonl |
| Query metric series | putnami cloud metrics <app> --window 1h --output=jsonl |
| Find slow traces | putnami cloud traces <app> --slow 500ms --output=jsonl |
All three queries are scoped to the linked workspace and environment. Cursors
keep paged reads bounded; logs --follow is the explicit SSE live-tail mode.