# App status, logs and troubleshooting on blitz.cloud

> What an app's status means on blitz.cloud, what the five tabs show, how to restore an earlier version, and how to fix why an app won't start.

Web page: https://blitz.cloud/docs/app-status-and-logs/
Updated: 2026-09-26

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.

## The app's page

Every app has a page with five tabs:

- Overview has the status, what to do when something is wrong, and this week's numbers. While a new version builds, you watch the build here step by step.
- Activity lists everything that happened to the app, with earlier versions to put back.
- Logs shows what the app prints, live.
- Environment holds the app's environment variables.
- Settings has the address, domains, port, where new versions come from, and switches like "Our page for its errors".

To rename an app, click its name at the top of the page. Only the name changes. The address stays the same.

## Statuses

| Status | What it means |
|---|---|
| Building | A new version is being built. A version that is already running stays online meanwhile. |
| Starting | The container is being pulled or started, or it hasn't passed its readiness check yet. |
| Online | The app is running and answering on its port. |
| Sleeping | Nobody visited for 15 minutes. The next visitor wakes it in about ten seconds. See [sleeping apps](https://blitz.cloud/docs/limits/#sleeping-apps). |
| Updating | An overnight update is on its way. The version before keeps running until the new one answers. |
| Needs attention | The app keeps crashing, has restarted itself 3 or more times while still answering, can't be scheduled, or can't be downloaded. |
| Stopped | The app crashed again and again, so we stopped it after 15 restarts. Nothing is lost. "Start it again" on its page starts it, and so does a new version. |
| Paused | You paused it, or we did, and the page says which. The address, settings and files are kept, and its memory goes back to your pool. An app we paused says why and asks you to write to us. |

## Uptime and traffic

The Overview shows how many requests the app answered this week and how much data it served. For every app that is awake we check once a minute whether it answers, and the Overview shows the result, like "99.8% this week" or "Down 12 minutes this week". A sleeping or paused app is not counted as down, and a check never keeps an app awake.

## When a build or start fails

When a build or a start fails and our own retries are used up, the Overview says what went wrong in one sentence and lists the steps that fix it, each with its own button: paste a key, set up a database, use another Dockerfile, or let us write one. What blitz.cloud can do safely, it does by itself. It never makes up a key or an address. More on this in [deploy a GitHub project](https://blitz.cloud/docs/deploy-from-github/).

## 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 wants to run as root, the machine's administrator." The image expects root, and the app was set up before root was allowed. Restart it and it starts as root, inside its own gVisor sandbox. An app built from your code does the same after its next build.

"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](https://blitz.cloud/docs/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.

## How long starting takes

Starting is usually a matter of a few minutes, and the first start is the slowest. Here is what we measured in September 2026:

- An app from the App Store: half of the installs were online within about four minutes. Small apps like Memos need about a minute. Bigger ones like Nextcloud set themselves up on their first start and take several minutes. Later starts skip that setup.
- A GitHub project builds first. Half of all builds finish in about two minutes, and nine in ten within about six. A build sometimes waits a few minutes for a build server of its own before it begins.
- A Docker image is downloaded first. A small image takes seconds, a large one up to about a minute.
- A sleeping app wakes for its next visitor in a few seconds.
- An app whose files nobody used for 7 days gets them back first, which adds a minute or two.

The longest waits come from "There is no room on blitz.cloud for this app right now". We add a server when that happens and the app starts on its own, usually within a few minutes. There is nothing to do on your side.

What helps:

- Give the first start at least five minutes before you change anything. Deleting the app and installing it again starts over from the beginning and makes the wait longer.
- Look at the Logs tab. When the app is printing lines, it is starting and just not ready yet.
- For your own image or project, keep the image small and open the app's port as early as you can. An app counts as Online once it answers on its port, so a long migration before that shows as Starting until it is done.
- An app that people should never wait for can stay awake. "Keep it awake" on the Settings tab is part of Pro.

## 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 enter it under Port on the app's Settings tab. The app restarts once.

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:

```bash
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.

## Activity and earlier versions

The Activity tab lists everything that happened to the app, newest first and grouped by day: builds, versions going live, restarts, sleeps and wakes, stops, setting changes and domains. The version running now is pinned on top. The filters Everything, Versions, Problems and Changes narrow the list. Changes shows every change to how the app is built or started, with who made it and why. Settings appear by name, never with their values.

Each of the last 10 versions that went live has a "Put this version back" button. The build log of a version opens right there.

## What visitors see when the app isn't running

When no app is running behind the address, visitors see a blitz.cloud page that says why: the app is asleep, paused (and by whom), starting, stopped after crashing, or building. A sleeping app rarely gets that far: the first visit waits for it to wake up and then gets the app's own answer, forms included. The waking page only shows if waking takes more than about five seconds.

Error pages the app sends itself, such as its own 500 or 503, reach visitors exactly as the app wrote them. To show our page for those too, switch on "Our page for its errors" on the app's Settings tab. Leave it off for an API, because programs that call it expect its own answers.

## Mail when something happens

We send you a mail when a new version fails or goes online, when we stop an app, when a restore finishes and when an overnight update ran. Each of these can be switched off under Settings > Notifications, or with one click in the mail. Mails about your account, security and billing are always sent.

## 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 when they stop answering, only when they crash.

An app that crashes is started again each time, with longer waits in between. After 15 restarts we stop it, mark it Stopped and send you a mail.

## Is it your app or blitz.cloud?

If several of your apps stop answering at once, or the dashboard won't load, look at [status.blitz.cloud](https://status.blitz.cloud/) before you change anything. It says whether a part of blitz.cloud has a problem right now, and it runs on its own server outside the platform, so it still answers when blitz.cloud doesn't.

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