Configuration

Logs and metrics

Read build logs, runtime logs and HTTP requests, check health, and see traffic, errors, CPU and memory.

Elula reads logs and metrics from Cloud Logging and Cloud Monitoring in your Google Cloud project. Everything here is available from the CLI and from the app's Logs and Metrics tabs.

Build logs

Build logs show what Cloud Build did: installing dependencies, building, pushing the image.

elula logs                         # the latest deployment
elula logs --deployment 7c41e0a2   # a specific deployment (ID or prefix)

In a terminal, elula deploy and elula preview stream the build log while they run. When their output isn't a terminal (an AI agent, CI, or a pipe), they show only the steps and progress, and the end of the build log if it fails; add --logs for the full log, or run elula logs afterwards. In the dashboard, open Logs and pick build.

Note: A successful build doesn't mean the app started. If a deployment failed after the build, the reason is usually in the runtime logs.

Runtime logs

Runtime logs are what your app writes to stdout and stderr.

elula runtime-logs                    # stream live, starting 10 minutes back
elula runtime-logs --since 1h         # start further back: 10m, 30m, 1h, 3h
elula runtime-logs --search error     # only lines containing "error" (case-insensitive)

elula runtime-logs keeps streaming until you press Ctrl+C. The furthest it goes back is 3 hours.

If the app has no running service yet (for example, the first deploy built fine but the container wouldn't start), Elula prints the logs from that last rollout instead of a live stream.

In the dashboard, open Logs and pick runtime. You can filter by text and by level (all, warn and above, errors). When the last deploy failed, the tab shows its error above the logs.

Note: Log what you need to debug to stdout or stderr. Files written inside the container are not collected.

HTTP requests

See recent requests to the app, newest first, with method, path, status and latency:

elula http-logs                       # 4xx and 5xx errors (default)
elula http-logs --status 5xx
elula http-logs --status 2xx --limit 100
elula http-logs --json

--status takes errors (4xx and 5xx), 2xx, 3xx, 4xx or 5xx. --limit is 1 to 200, default 50.

Metrics

elula metrics               # the last hour
elula metrics --hours 24    # 1, 6 or 24
elula metrics --json        # summary plus the raw time series

The summary shows:

Requests, split into 2xx, 3xx, 4xx and 5xx
Error rate (5xx) and client error rate (4xx)
CPU and memory: average and peak of the 99th-percentile utilization

The dashboard's Metrics tab shows the same data as charts for the last hour, 24 hours or 7 days. Metrics are for services; jobs don't have a Metrics tab.

Health

elula health
elula health --json

Prints one word:

Status	Meaning
`up`	Cloud Run reports the service as ready
`down`	Cloud Run reports the service as failed. The reason is printed
`deploying`	A rollout is in progress
`unknown`	Elula couldn't check, for example because the app hasn't been deployed

elula health exits with code 1 when the app is down, so you can use it in scripts:

elula health || echo "app is down"

Health comes from Cloud Run's own status for the service. Elula doesn't send requests to your app to check it.

Rate limits

Cloud Logging limits how often logs can be read. If you hit the limit, you get "Cloud Logging is temporarily rate-limited. Please try again in a moment." Wait a few seconds and retry.

Using these with an AI assistant

elula http-logs, elula metrics and elula health all accept --json, which is easier for scripts and AI assistants to read. See Use Elula with your AI.