Guides

Logs and metrics

Investigate current application output, search archived logs, and inspect builds and resource usage.

Live output and searchable history

Open a service on the environment canvas and select Logs. Live reads current container output; History searches archived application output across restarts and deployments. Searchable history depends on your organization’s plan and is capped at 30 days. Logs are diagnostic records, not backups of your application data.

Usage is separate from live network charts

Live network RX/TX charts include internal traffic and are not an invoice or a transfer meter. Outbound transfer is included with no fixed allowance and no overage charge, under the fair-use terms. Read collection timestamps and missing-data indicators; an unavailable measurement is not zero.

Runtime logs

Open an app and go to the Logs tab. The viewer polls for new output every few seconds, pauses when the tab is in the background, and offers filters for free text, log level, service, and hiding health-check noise.

bash

# Recent output$ codaracloud logs my-api # Keep polling for new lines$ codaracloud logs my-api --follow # More history from the current container$ codaracloud logs my-api --tail 500

Limit	Detail
Maximum lines	1000 per request, shared across all of the app’s replicas.
History	Live shows what current containers still hold. Use History for archived output across restarts, within your plan’s retention window.
Live updates	The console’s Live view refreshes every 3 seconds, and the CLI’s `--follow` polls every 2 seconds. Neither is a persistent stream, so a brief gap can drop lines.

Log levels are inferred

Codara guesses a line’s severity from its text so the viewer can colour and filter it. It is a display convenience, not something your app reports. Structured JSON logs with an explicit level field will classify far more reliably than free text.

Search archived logs

In Logs → History, choose the last hour, 24 hours, 7 days, 30 days, or a custom range. Preset ranges search immediately. For custom dates or case-sensitive search text, click Search history. The result caption shows the actual searched interval and the history available on your plan. Searches return at most 1,000 matching lines; narrow the range or add text if the result limit is reached. Export downloads the filtered, loaded results, not the entire archive. The standalone app Logs page has the same controls.

Whole-environment logs

The environment log explorer merges output from every service in one environment, which is the fastest way to follow a request across services. In a large environment the view samples across services and tells you when it has truncated, so treat it as a survey rather than a complete record. With one app it overlaps that app’s Live view; with several apps it combines their output. Archived search is available in each app’s History tab.

Build logs

Build output appears on the release page while the build runs, with a stepper showing which phase it is in. Read it there.

Build logs are deleted after 24 hours

About a day after a build finishes, its logs are removed and the release page shows nothing. If a build failure needs investigating, copy the output while it is still there. There is no CLI command for build logs — use the console.

Metrics

Every app has a Metrics tab showing CPU, memory, network, replica count and restarts over time.

bash

# Current usage with sparklines$ codaracloud metrics my-api # Over a longer window$ codaracloud metrics my-api --window 24h

Available windows are 5m, 1h, 24h, 7d and 30d.

Metrics can be viewed for up to the last 30 days

That is the longest window, 30d. For longer history, send metrics to your own monitoring service.

Restarts are the signal to watch

A climbing restart count almost always means the container is crashing and being restarted, or failing its health check. Check the logs and the health check path before looking anywhere else.

Database metrics

Dedicated databases report CPU, memory and storage. Shared databases report storage only, because CPU and memory belong to the pooled instance and cannot honestly be attributed to one tenant — those charts stay empty rather than showing a misleading zero. Reading database metrics through a token requires both a database read scope and metrics:read.

Deploy notifications

A project can send a signed HTTP request to an endpoint you control whenever a deployment succeeds or fails — useful for posting into Slack or triggering downstream automation. Configure them in the project’s settings under Webhooks.

Header	Contains
X-Codara-Event	`deployment.succeeded`, `deployment.failed` or `test`
X-Codara-Delivery	A unique id for this delivery attempt
X-Codara-Timestamp	Unix seconds
X-Codara-Signature	`sha256=<hex>` — an HMAC over the timestamp and body, using the signing secret shown once when you create the endpoint

Always verify the signature before trusting a payload, and compare digests in constant time. Any 2xx response counts as delivered; anything else is retried with backoff for up to 8 attempts. The console shows the last 20 deliveries with their status codes.

Filling the gaps

Given the retention limits, most production apps will want to send their own telemetry somewhere durable:

Errors — an error tracker gives you stack traces and grouping that container logs never will.
Logs you must keep — ship them to a hosted log service from your app.
Uptime — an external monitor hitting your health endpoint is the only thing that tells you the app is unreachable from outside.

Last updated 26 September 2026