App status, logs and troubleshooting on blitz.cloud

Every app on blitz.cloud shows one status: Starting, Online, Needs attention, or Paused. When something is wrong, the app page explains it in one sentence and shows the last lines the app printed. Most problems with Docker images come from three things: the image needs root, it is built only for arm64, or it listens on a different port than the one chosen.

Statuses

Messages you might see

"The app starts and then stops again straight away." The container starts and exits in a loop. The last log lines are right under the message and usually say why: a missing environment variable, a database it can't reach, or a permission error when writing a file.

"This app insists on running with full access to the machine, which blitz.cloud does not allow." The image needs to run as root. Every app runs as uid 1000 and group 1000 with all Linux capabilities dropped, and that doesn't change per app. Use an unprivileged variant of the image, or build your own that runs as a normal user.

"We couldn't download this app. Check the name is spelled right and that it is public." The image name or tag is wrong, or the repository is private. Private images aren't supported yet.

"Your plan's memory is fully used, so this app has nowhere to start." Pause or delete another app, or delete a database you don't use. See limits.

"There is no room on blitz.cloud for this app right now." The cluster itself is full. We get alerted and add servers; the app starts on its own once there is room.

An app that needs a database but has none connected says so and names the engine. Give it one from the Databases page.

The app stays on "Starting" forever

This almost always means the container runs, but nothing answers on the chosen port. There is no timeout that turns this into an error, so it just keeps waiting.

Check the logs for the port the app actually listens on. Then delete the app and deploy it again with that port under Advanced settings. The dashboard can't change the port of an existing app yet.

Also check that the app listens on all interfaces (0.0.0.0), not only on localhost or 127.0.0.1. Traffic reaches the container from outside it.

arm64-only images

Our servers are x86 (amd64). An image published only for arm64, which is common for images built on an Apple Silicon Mac without --platform, will stop on startup. Rebuild with:

docker buildx build --platform linux/amd64 -t yourname/yourapp:1.0 --push .

Live logs

The Logs tab streams output from the app as it happens, starting with the last 500 lines. You don't configure anything.

• Each account can have 2 log streams open at a time.
• A stream closes after 5 minutes without new output or after 30 minutes in total. The output says so, and one button reconnects.

Restart, pause, resume and delete

• Restart starts the app fresh. Use it after changing environment variables.
• Pause stops the app but keeps its address, settings and files. Its memory goes back to your plan.
• Resume starts it again. It counts against your limits like a new app, so it only works if there is room in your plan.
• Delete asks you to type the app's name. If it has a database, you choose whether to keep or delete it. The app's files on disk are deleted.

Deployment history

The Deployments tab lists every time the app went online, what caused it and whether it worked.

Automatic restarts

Apps from the App Store have a health check that knows what "working" means for that app, and are restarted if they stop answering. Apps from your own Docker image are not restarted automatically.

Still stuck? Write to hallo@blitzworks.io with your app's address.