Logs and health

Runtime logs

Runtime logs come from application stdout and stderr. They are useful for startup failures, port mistakes, missing configuration, and runtime exceptions.

Logs help answer:

• Did the app start?
• Did the start command run?
• Is the listener port correct?
• Is configuration or an environment variable missing?
• Did application code throw at runtime?

Logs do not prove domain ownership or certificate readiness. DNS and TLS issues belong in access and certificate status.

Health summary

Health summaries combine deployment, runtime, health policy, proxy, and public access observations to guide retry, repair, or rollback.

Health summaries should include:

• Latest deployment status and failed phase.
• Runtime process state.
• Health profile and latest check result.
• Network profile and proxy target.
• Generated access status.
• Custom domain and TLS readiness summary.

Entrypoints

The Web console should place logs and health near resource or deployment details. Users should not need raw server logs to understand deployment result.

The CLI should expose logs and health summaries for SSH and CI workflows.

The HTTP API should return paginated logs, health summary, and structured status for automation.

Recover from results

Common decisions:

• Logs show port conflict: fix network profile or start command.
• Logs show missing variable: fix environment variables and redeploy.
• Health check times out: adjust health path, timeout, retries, or start period.
• App is healthy but generated access fails: inspect proxy readiness and access route.

Related pages: Health and network profiles and Generated access routes.

CLI examples:

Read runtime logs

appaloft resource logs res_web --tail 100

Read health summary

appaloft resource health res_web --checks --public-access-probe

HTTP API example:

Runtime logs

GET /api/resources/res_web/runtime-logs?tailLines=100