Docs / Operate

Logs, metrics and alerts

Dawnrose keeps four kinds of logs, collects metrics for every service, tells you when a service needs more resources, and sends notifications to the channels you choose.

Logs

Open a deployment from the Deployments tab to see its build, deploy and HTTP logs. The Logs tab streams runtime logs live and can be paused. The project’s Logs page, in the rail on the left, shows the runtime logs of every service in the environment together; Search history runs the filter on the server over older lines.

A build log keeps everything up to 10 MB; after that it keeps only errors and deploy steps. HTTP logs keep the most recent 2,000 requests per service. Logs of deployments that were removed, failed, cancelled or skipped are deleted once the deployment is 30 days old.

Structured logs and levels

A line that is a JSON object becomes a structured entry. The message comes from message, msg or text, the level from level, severity or lvl (numeric levels such as pino’s are understood), and the other fields become attributes you can filter on. A plain line that starts with a level such as [error] or warn: gets that level. Anything else is error on stderr and info on stdout.

{"level":"error","msg":"payment failed","status":502,"req":{"method":"POST","path":"/checkout"}}

Log filter syntax

The same syntax works in the dashboard, in dawn logs --filter and in the agent’s log tools.

Terms separated by spaces must all match. OR separates groups, and a line matches if any group matches.

dawn logs -f --filter '@level:error -healthz'

Metrics

The Metrics tab charts CPU, memory, network in and out, requests, 4xx and 5xx errors and latency for the last 1 hour, 6 hours, 24 hours or 7 days, with markers for deployments. The Observability page shows current usage for each service. dawn metrics and the agent’s get_metrics return the same numbers.

CPU, memory and network samples are kept at full detail for a day, then averaged into 5-minute points. How long they are kept depends on the plan: 1 day on Trial, 7 days on Hobby and 30 days on Pro. Request, error and latency figures cover up to the last 24 hours. Build and deploy logs are kept for 7 days on Trial, 14 on Hobby and 30 on Pro, up to a workspace total of 0.5 GB, 5 GB and 20 GB.

Scaling advice

Dawnrose watches how much of its limits each service uses. It flags a service when, over 10 minutes, most samples show CPU at 80% or more of its limit or memory at 85% or more, and also when a replica is killed for running out of memory. The service’s Deployments tab then shows what is wrong and a suggested change, and the workspace gets a service.scaling notification, repeated at most once a day.

• CPU: more replicas first, if the service has no volume and the plan allows them. Otherwise a higher CPU limit, then a bigger plan.
• Memory: a higher memory limit, then a bigger plan.

Click the suggestion button (for example Use 3 replicas) to stage the change, then deploy it. Agents see the same advice as scaling on the service and apply it with update_service and deploy_changes. The advice clears when usage drops back (CPU below 60%, memory below 70%) and after a new deployment.

Alerts

An alert notifies your channels when a metric stays above a threshold. Add one under Settings → Notifications, in the Alerts section: pick CPU, Memory or HTTP 5xx rate, one service or any service, a percentage and a number of minutes, then click Add alert.

• CPU: percent of the service’s CPU limit across its replicas.
• Memory: percent of the memory limit.
• HTTP 5xx rate: percent of requests in the last 5 minutes that returned a 5xx status.

When the value stays above the threshold for the whole duration, the alert fires (monitor.firing). When it drops back below, a monitor.resolved notification follows. Managing alerts needs the admin role. Agents use create_alert.

Notification channels

Under Settings → Notifications, in the Channels section, click Add channel. Pick a type, enter its target and choose the events to send. Send test checks a channel, and the switch turns it on or off.

Events you can subscribe to:

Webhook channels receive a JSON body with event, title, message, level, url, fields, orgName, projectName, serviceName and sentAt, and an x-dawnrose-event header. If the channel has a secret, each request carries x-dawnrose-signature: sha256=<hex>, an HMAC-SHA256 of the body with the secret. Agents can set the secret with add_notification_channel and the config {"url": "…", "secret": "…"}. Webhook URLs must resolve to public addresses.

Email owners when something breaks is on by default. While the workspace has no email channel, owners get failed deploys, crashes, alerts, scaling advice, usage warnings and limits, and failed backups by email. Managing channels needs the admin role.

Activity log

Every change is recorded with who made it: a person, an AI agent (marked as AI) or Dawnrose itself. The activity button at the top of a project opens its history beside the canvas (View all opens the full page), Settings → Audit log shows the whole workspace, and the Connect agent page shows recent agent activity. Agents read it with get_activity.

Debugging a service

• Get a shell inside it. The Console tab opens a terminal in a running replica; dawn exec and the agent’s exec_command run single commands. See The Console tab.
• Send it a request. The agent’s http_request tool sends an HTTP request straight to a running replica over the private network, on any port, and returns the status, headers and body. It works before the service has a domain.
• Hand it to your agent. A failed or crashed deployment shows Ask Claude to fix this. Copy prompt copies a request with the project, environment, service and deployment ids to paste into your agent.