Status and logs

These entries start from what read_status or read_logs returns. Read the status describes every member of the status, and Read logs and counters every log source.

read_status shows the production state while development deploys

Cause. A read_status call that gives no environment returns production's top-level members, whichever environment is deploying. The top-level state, version, and hostname are then production's. Each environment's own record, the development deploy among them, is in the environments object.

Check. The top-level environment member is production. The summary gives each environment its own sentence, then says that the top-level members describe production. environments.development.deploy.state is deploying, and its step shows where the deploy is.

Remedy. Call read_status with environment: "development" and wait_seconds until the top-level state leaves deploying. The top-level members then describe development, and the summary says so. A deploy's next call already gives the deploy's environment, so make that call unchanged. The same record is also at environments.development.deploy.

The deploy succeeded but a route responds with a 500

Cause. A deploy succeeds when the application starts and its health path answers 200. The health check calls that one path and no other, so a route it does not call can still fail. The platform records each request your application answers with a 5xx status.

Check. Call read_status for the environment. If any request failed since the serving version started, the summary says how many, and on how many paths. The application.server_errors member lists each failing path with its count, its last status, and the time of the last failure. If its read member is skipped, a deploy is running, so read again when it ends. A failure reaches the count a few seconds after the request ends, so read again if the newest one is missing. The success answer and the command's checked: line say the check requested the health path alone.

Remedy. Read the application's own output for the failing path: call read_logs with source: "container", or source: "app" for what the application wrote through the logging package. Fix the route and deploy again. The member counts from the new version's start, so a fixed route leaves the list. The failing paths in the status describes every member.

A read_logs call across all sources, or with source: "router", whose entries include the 5xx record names the container read and its since in its detail. Where many lines follow that time, raise limit or add contains. contains returns the matching lines alone, so for the rest of a stack trace, which names the file and line of your code, read again without it, from the matched line's time. On a pod, the console ends with the pod, so only the version serving now can be read. From a 5xx record to the error your application wrote describes it.

The logs show SIGTERM lines after a promote or while the application is idle

Cause. Two stops write shutdown lines that are no fault of the serving version. During a promote or a replacing deploy, the platform stops the old version's container with SIGTERM. A container app that scales to zero while idle is stopped with SIGTERM too. In either stop, npm can print npm error lines as it ends.

Check. Call read_logs with source: "container". Each line from the container being replaced has [retiring] after its stream. Each line the idle-stopped container wrote from the stop has [idle-stop] there instead. A line from the new version is never marked [retiring].

Remedy. None is needed: the serving version keeps responding, and the next request after an idle stop starts the application again. A read within about a minute of the stop may leave its lines unmarked, so read again. A pod's console marks neither stop, because it ends with the pod.

The console says no migration was applied at a start

Cause. The migration function applies each file once and records it in the schema_migrations table. A start that finds every file recorded applies none, so a line that prints what the start applied prints none. A restart starts this way, and so does a copy waking from its idle stop. A deploy also starts this way after a local run applied the file to the same database.

Check. Request a route that reads a table the migration creates. If it responds, the schema is in place. The start that applied the file printed its name, where the console still contains that start's lines.

Remedy. None is needed. To change the schema, add a new migration file, and never edit or rename an applied one. Keep the schema as migrations explains the function.