Finding and fixing errors: logs, restart loop and reinstalling

If a container reports a problem, your project overview will display a notification with steps to resolve it (Container Hosting at a glance). These steps take you directly to the logs, variables or history. This article explains each of these tools in detail.

Reading logs

Open the container and go to the Logs tab. You will see the container’s most recent output; the view updates automatically.

• Lines - specifies how many of the most recent lines are displayed.
• Warnings & errors only - hides all other lines. Errors are highlighted in red, warnings in yellow, with the most recent error shown at the top.
• Copy for support - copies the displayed lines so that you can paste them into a support ticket.
• Bot scan · rejected - requests for files such as .env or .git come from automated scanners. They are common, are rejected and are harmless.

The application returns a 500 status code

If the check chain of the web address shows ‘Responds with status 500’, the address, certificate and container are functioning correctly - the error lies within the application. The most common cause is a rejected database login, which appears in the logs as ‘Access denied for user’, for example. Proceed as follows:

1. Compare the username, password and host in the application with the details in the database container (environment variables and secrets).
2. Note: database images only apply login details on their first start. If a password is changed later, you must set it in the database itself, for example via the console.
3. Check that both containers are on the same network (networks and firewall).
4. Restart the application after making the change.

Restart loop

If a container shuts down immediately after starting, it will keep restarting. The customer area then shows the status Restart loop. Common causes:

• Required variables or login details are missing - for example, many database images require a root password.
• A custom start command is incorrect.
• The container has insufficient RAM.

The exact cause can be found in the logs, usually in the last few lines. Use Stop to halt the container until you have corrected the settings.

Recreate or reinstall?

You’ll find both options at the very bottom of the container’s settings:

• Recreate pulls the image again and recreates the container with the same configuration. Data in volumes is preserved. This is helpful if the container freezes or files in the image are corrupted.
• Reinstall deletes all data in this container’s volumes and sets it up as if it were being started for the first time. Before doing so, we automatically create a snapshot of this container’s volumes that you can use to revert to a previous state. To confirm, type in the container’s name and confirm by signing in again.

Below that you will find Delete container. You choose in the dialogue which volumes are deleted as well - more on this in the article Storage and file browser.

Operation history

In the History tab of your project, each operation is listed with its time, container, result and who triggered it: you, Support, the system or Monitoring. Using the Open and Failed filters, you can quickly find the step that didn’t work, along with the reason why.

Console in the browser

With the Console option, you can open a command line directly in the container, in the Console tab on the container’s page:

1. Click Start console and briefly confirm your login, for example using a passkey or two-factor authentication.
2. Enter your commands. They will run directly within the container.
3. End the session with Disconnect.

Sessions end after 30 minutes of inactivity, or after 4 hours at the latest. Up to three sessions can run simultaneously per project; content is not recorded. Changes made outside of volumes will be lost upon the next restart.