Goal
Read an app’s runtime logs, and use the health summary to understand the combined status of deployment, runtime, proxy, and access URL in one call.
When to use this task
- The app failed to start or is behaving unexpectedly, and you need to see what it printed itself.
- You need to decide “should I retry, fix configuration, or roll back next.”
Prerequisites
- At least one deployment attempt exists (successful or failed).
Inputs and defaults
| Input | Description | Default |
|---|---|---|
--tail | Only show the last N log lines | All (explicitly specifying is recommended to avoid excessively long output) |
--checks | Include detailed check items with the health check | Off |
--public-access-probe | Include a public access probe with the health check | Off |
--runtime-probe | Inspect the current Docker runtime instance in live mode | Off |
CLI steps
# Read the last 100 lines of runtime logs
appaloft resource logs res_web --tail 100
# Read live health and reconcile the current runtime and public access
appaloft resource health res_web --live --checks --runtime-probe --public-access-probeHTTP/API steps
GET /api/resources/res_web/runtime-logs?tailLines=100
GET /api/resources/res_web/health?mode=live&includeChecks=true&includeRuntimeProbe=true&includePublicAccessProbe=trueExpected output and status
Runtime logs come from the app process’s stdout/stderr, and are good for answering: did the app start, did the start command execute, is the listening port correct, are config/environment variables missing, did the app code throw a runtime exception. Logs are not good for judging domain ownership or certificate readiness — check the related Access status for those instead.
The health summary merges the following into a single call: the most recent deployment status and failed phase, the runtime process state, the health check policy and most recent check result, the network profile and proxy target, generated access URL status, and a custom domain/TLS readiness summary.
The Resource detail page inspects the current runtime during a live refresh. Even when the latest
Deployment is succeeded, the current Resource status becomes stopped if Docker confirms that
the runtime-owning container no longer exists. A failed replacement remains deployment history and
does not replace an older successful runtime that is still serving. If SSH, the Docker daemon, or the probe timeout
only makes observation unavailable, status stays unknown with
resource_runtime_inspection_failed; Appaloft does not turn “cannot observe” into “stopped.”
Project lists and the sidebar use compact health and do not start one remote runtime inspection per
Resource.
Verification
Match against this table to identify the root cause:
| Symptom | Recovery direction |
|---|---|
| Logs show a port conflict | Fix the Network Profile or the start command |
| Logs show a missing environment variable | Fix the variable set under Configuration Precedence, then redeploy |
| Health check times out | Adjust the health check path, timeout, retry count, or startup grace period |
| Latest Deployment succeeded, but current status is stopped | The current runtime instance is gone; inspect logs and the Deployment timeline, then use recovery readiness to choose Redeploy, Retry, or Rollback |
Current status is unknown with resource_runtime_inspection_failed | Restore SSH/Docker observability and refresh; do not infer that the container stopped from this probe failure alone |
| App healthy but the generated access URL fails | Check Proxy Readiness and Access status |
Rollback / recovery
If you just want to restart the current runtime (this won’t rebuild, and won’t refresh config/secrets/dependency bindings), use runtime control:
appaloft resource runtime restart res_webRestart is not the same as Redeploy — if you’ve changed source code, environment variables, secrets, the Runtime/Network/Health Profile, storage mounts, or dependency bindings, you must use Redeploy, Retry, or Rollback (see Rollback And Recovery); Restart doesn’t apply those changes.
If Start is blocked (for example runtime metadata is missing or stale, the resource is archived, or a concurrent deployment exists), the health summary gives the blocking reason; in that case switch to Redeploy so the latest configuration forms a new deployment, instead of repeatedly retrying Start.
Troubleshooting links
Related reference pages
If an AI agent is doing follow-up checks after completing a deployment, prefer returning appaloft deployments timeline <deploymentId>, appaloft resource diagnose <resourceId>, and appaloft deployments recovery-readiness <deploymentId> in that order, rather than sending the user to dig through raw logs on the server themselves.