Where are my app's logs in Aozumi?

Open the app's Deployments tab and select a release to read its build output and runtime logs. Agents can read the same logs, redacted and size-bounded, with the MCP logs tool.

Can Aozumi alert me in Slack?

Yes. Add a Slack incoming webhook under Settings → Alerts and choose which alerts it receives: failed releases, failing health checks, a high server-error rate, and their recoveries. You can also send them to your own HTTPS endpoint, signed with HMAC-SHA256.

Why does my deploy fail with a health check error?

The app did not answer in time on the port Aozumi expects. Make sure the server listens on the PORT environment variable rather than a fixed port, starts quickly, and returns a 2xx response from its health endpoint.

Logs and health

Read build and runtime logs, understand app status, follow 30 days of health history, and get Production alerts in the console, in Slack, or at your own webhook.

App status

Deploying: A release is queued or building. It is not live yet.
Healthy: The latest Production release is live.
Asleep: The app is idle and will start on the next visit. See sleep when idle.
Waking: A visit is starting the app.
Failed: The latest release did not become healthy. Read its logs.
Paused: The app has been paused and is not serving.
Needs configuration: Something is missing before the app can run, often a variable.

Build and runtime logs

Select a release in the Deployments tab to follow its progress and read its logs. Read the build output first when a build fails; read the runtime logs when the app built but did not start or stay running.

Agents read logs with the MCP logs tool. It returns redacted, size-bounded output with Aozumi's diagnosis, defaults to Production, and accepts another environment.

Common failures

Aozumi reads the logs of a failed release and adds a diagnosis when it recognises the cause:

A required secret may be missing: Add the variable named in the log, then deploy again.
The app did not stay running: Check the start command and listen on PORT. Do not hard-code port 3000.
The health check did not pass: Bind to PORT, start within the grace period, and return a 2xx response from the health endpoint.
The runtime was stopped: A stop request, not a build failure: pause, replacement or idle sleep. Redeploy if the app should be running.

Health checks and history

A new server release has to become healthy before it takes traffic; until then the previous release keeps serving. Static sites switch once their files are verified. Turn on health checks for a public app and Aozumi checks it through its gateway every 5 minutes while it is live and keeps 30 days of health history, which the app's health view shows next to recorded visitor traffic.

Incidents and notifications

Production alerts appear in your workspace inbox with a link to the affected app. Each member marks them read separately. Aozumi raises three kinds, each with a matching recovery:

A release failed. A Production release or operation failed. The previous healthy release keeps serving. Recovered when a later release is healthy.
Health checks are failing. Three health checks in a row, about 10 to 15 minutes, got no healthy answer from the live release. Recovered on the next healthy check. Needs health checks turned on for the app.
The error rate is high. At least 10% of Production requests failed with a server error in two 5-minute windows in a row (with at least 20 requests and 5 failures in each). Recovered after two windows under 5%. Traffic to previews and other non-Production environments never counts.

Each problem alerts once, not on every check, and recovers once.

Alerts in Slack or your webhook

Owners and admins can send alerts outside the console from Settings → Alerts. Add up to 10 channels per workspace and choose which alerts each one receives. Use Send test to confirm a channel works.

Slack: paste a Slack incoming webhook URL (https://hooks.slack.com/services/…).
Signed webhook: any public HTTPS endpoint on port 443. Each request is a JSON body with headers x-aozumi-event, x-aozumi-delivery, x-aozumi-timestamp and x-aozumi-signature. Verify it by computing HMAC-SHA256 of timestamp.body with the signing secret shown once when you add the channel, and comparing it to the signature (sha256=…).

URLs are encrypted and never shown again after you add them. Aozumi does not follow redirects, retries failed deliveries with backoff, and shows each channel's last delivery result. Private addresses, IP literals and AOZUMI's own domains are refused.

Questions

Where are my app's logs in Aozumi?: Open the app's Deployments tab and select a release to read its build output and runtime logs. Agents can read the same logs, redacted and size-bounded, with the MCP logs tool.
Can Aozumi alert me in Slack?: Yes. Add a Slack incoming webhook under Settings → Alerts and choose which alerts it receives: failed releases, failing health checks, a high server-error rate, and their recoveries. You can also send them to your own HTTPS endpoint, signed with HMAC-SHA256.
Why does my deploy fail with a health check error?: The app did not answer in time on the port Aozumi expects. Make sure the server listens on the PORT environment variable rather than a fixed port, starts quickly, and returns a 2xx response from its health endpoint.

Checked against the product on 9 October 2026.