Logs & Status

App status

Your App's Status page is the one place that shows everything about its current state at a glance: its active release, the build behind it, its running replicas, and its domains.

Deploys are asynchronous, so this page is how you watch one happen — it updates as your deploy moves through its states:

• pending — the deploy was accepted and is about to start.
• building — your source is being built into a container image.
• waiting_for_server — the build is done (or still running), and Raklane is starting a server with room for your app. Usually a few minutes; it continues by itself.
• rolling_out — new replicas are starting and being health-checked next to the old ones.
• active — the release is live and serving traffic.
• baking — traffic has already cut over, but Raklane is still keeping the previous release warm as a safety net for a short window (see Deploying Your App).
• failed — the build or the new replicas' health check failed; whatever was running before is untouched and still serving traffic.
• canceled — you canceled the deploy before it finished.
• rolled_back — a problem was caught during the bake window and Raklane automatically reverted to the previous release.
• unreachable — Raklane can't currently confirm the release's state, usually because the BYOC server it runs on is offline. The app is often still running and serving. It returns to active by itself once the server reconnects.

If an App has never been deployed, its status page just shows that — no error, nothing broken, simply nothing running yet.

Reading logs

Raklane keeps two separate kinds of logs:

• Build logs — the output of turning your source into a container image (dependency install, buildpack detection, compile steps). These are grouped by stage, so you can jump straight to, say, the dependency-install step instead of scrolling through the whole build. This is the place to look when a deploy fails before your container ever starts.
• Runtime logs — your running container's combined stdout/stderr, exactly what your app itself printed. This is the place to look for a stack trace, a startup error, or anything your application logged once it's actually running.

The Status page tells you that something failed and often a structural reason why (e.g. a health check timeout or an image pull failure) but not the underlying output — Logs is where the actual error message lives.

Logs follow your App's most recent deploy, whether or not it succeeded — so if a deploy is failing, its logs are exactly where to look for why.

Typical troubleshooting order

1. Check the Status page — is the release failed, or still in progress (building, waiting_for_server, rolling_out)?
2. If failed, check the failure reason shown there — it usually tells you whether the problem was the build itself or the running container failing its health check.
3. Check Logs for your app's own output around the failure — this is almost always where the real error message is.

If the app is running but slow, crashing under load, or being killed, check Metrics & Processes — out-of-memory kills and CPU throttling show up there, with hints on what to change.

See Troubleshooting for fixes to the specific problems you're most likely to hit.