App-Status, Logs und Fehlersuche auf blitz.cloud

Jede App auf blitz.cloud zeigt einen Status: Starting, Online, Needs attention oder Paused. Wenn etwas nicht stimmt, erklärt die App-Seite das in einem Satz und zeigt die letzten Zeilen, die die App ausgegeben hat. Die meisten Probleme mit Docker-Images haben einen von drei Gründen: Das Image braucht Root, es ist nur für arm64 gebaut, oder es lauscht auf einem anderen Port als dem gewählten.

Die Seite einer App

Jede App hat eine Seite mit fünf Tabs:

• Overview (Übersicht) zeigt den Status, was zu tun ist, wenn etwas nicht stimmt, und die Zahlen dieser Woche. Während eine neue Version gebaut wird, siehst du den Build hier Schritt für Schritt.
• Activity listet alles, was mit der App passiert ist, samt früherer Versionen zum Zurückholen.
• Logs zeigt live, was die App ausgibt.
• Environment enthält die Umgebungsvariablen der App.
• Settings hat Adresse, Domains, Port, woher neue Versionen kommen, und Schalter wie "Our page for its errors".

Um eine App umzubenennen, klick oben auf der Seite auf ihren Namen. Nur der Name ändert sich, die Adresse bleibt gleich.

Status

Verfügbarkeit und Zugriffe

Die Übersicht zeigt, wie viele Anfragen die App diese Woche beantwortet hat und wie viele Daten sie ausgeliefert hat. Bei jeder wachen App prüfen wir einmal pro Minute, ob sie antwortet, und die Übersicht zeigt das Ergebnis, etwa "99.8% this week" oder "Down 12 minutes this week". Eine schlafende oder pausierte App zählt nicht als ausgefallen, und eine Prüfung hält keine App wach.

Wenn ein Build oder Start fehlschlägt

Schlägt ein Build oder ein Start fehl und sind unsere eigenen Versuche aufgebraucht, sagt die Übersicht in einem Satz, was schiefging, und listet die Schritte, die es beheben, jeden mit eigenem Knopf: einen Schlüssel einfügen, eine Datenbank anlegen, ein anderes Dockerfile nehmen oder uns eins schreiben lassen. Was blitz.cloud gefahrlos selbst tun kann, erledigt es. Einen Schlüssel oder eine Adresse denkt es sich nie aus. Mehr dazu unter GitHub-Projekt ausrollen.

Meldungen, die du sehen kannst

"The app starts and then stops again straight away." Der Container startet und beendet sich in einer Schleife. Die letzten Log-Zeilen stehen direkt unter der Meldung und sagen meist, warum: eine fehlende Umgebungsvariable, eine nicht erreichbare Datenbank oder ein Berechtigungsfehler beim Schreiben einer Datei.

"This app wants to run as root, the machine's administrator." Das Image erwartet Root, und die App wurde eingerichtet, bevor Root erlaubt war. Starte sie neu, dann läuft sie als Root in ihrer eigenen gVisor-Sandbox. Eine App aus deinem Code macht das nach ihrem nächsten Build genauso.

"We couldn't download this app. Check the name is spelled right and that it is public." Name oder Tag des Images stimmen nicht, oder das Repository ist privat. Private Images werden noch nicht unterstützt.

"Your plan's memory is fully used, so this app has nowhere to start." Pausiere oder lösche eine andere App oder lösch eine Datenbank, die du nicht brauchst. Siehe Limits.

"There is no room on blitz.cloud for this app right now." Der Cluster selbst ist voll. Wir werden alarmiert und fügen Server hinzu; die App startet von selbst, sobald Platz ist.

Eine App, die eine Datenbank braucht, aber keine verbunden hat, sagt das und nennt die Datenbank-Engine. Gib ihr eine über die Seite Databases.

Wie lange ein Start dauert

Ein Start dauert meist ein paar Minuten, und der erste ist der langsamste. Das haben wir im September 2026 gemessen:

• Eine App aus dem App Store: Die Hälfte der Installationen war nach etwa vier Minuten online. Kleine Apps wie Memos brauchen etwa eine Minute. Größere wie Nextcloud richten sich beim ersten Start selbst ein und brauchen mehrere Minuten. Spätere Starts überspringen diese Einrichtung.
• Ein GitHub-Projekt wird zuerst gebaut. Die Hälfte aller Builds ist nach etwa zwei Minuten fertig, neun von zehn nach etwa sechs. Manchmal wartet ein Build ein paar Minuten auf einen eigenen Build-Server, bevor er anfängt.
• Ein Docker-Image wird zuerst heruntergeladen. Ein kleines Image braucht Sekunden, ein großes bis zu etwa einer Minute.
• Eine schlafende App wacht für ihren nächsten Besuch in ein paar Sekunden auf.
• Eine App, deren Dateien 7 Tage lang niemand benutzt hat, bekommt sie zuerst zurück. Das dauert ein bis zwei Minuten länger.

Am längsten wartet eine App bei "There is no room on blitz.cloud for this app right now". Dann fügen wir einen Server hinzu, und die App startet von selbst, meist innerhalb weniger Minuten. Du musst dafür nichts tun.

Was hilft:

• Gib dem ersten Start mindestens fünf Minuten, bevor du etwas änderst. Wer die App löscht und neu installiert, fängt von vorn an und wartet länger.
• Schau in den Tab Logs. Solange die App Zeilen schreibt, startet sie und ist nur noch nicht bereit.
• Beim eigenen Image oder Projekt: Halte das Image klein und öffne den Port der App so früh wie möglich. Eine App gilt als Online, sobald sie auf ihrem Port antwortet. Eine lange Migration davor zeigt so lange "Starting", bis sie fertig ist.
• Eine App, auf die nie jemand warten soll, kann wach bleiben. "Keep it awake" im Tab Settings gehört zu Pro.

Die App bleibt ewig auf "Starting"

Das heißt fast immer: Der Container läuft, aber auf dem gewählten Port antwortet nichts. Es gibt kein Zeitlimit, das daraus einen Fehler macht, also wartet sie einfach weiter.

Such in den Logs, auf welchem Port die App wirklich lauscht, und trag ihn im Tab Settings der App unter Port ein. Die App startet dann einmal neu.

Prüf auch, ob die App auf allen Interfaces lauscht (0.0.0.0) und nicht nur auf localhost oder 127.0.0.1. Der Traffic kommt von außerhalb des Containers.

Images nur für arm64

Unsere Server sind x86 (amd64). Ein Image, das nur für arm64 veröffentlicht wurde, stoppt beim Start. Das passiert oft bei Images, die auf einem Mac mit Apple Silicon ohne --platform gebaut wurden. Neu bauen mit:

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

Live-Logs

Der Tab Logs streamt die Ausgabe der App in Echtzeit, beginnend mit den letzten 500 Zeilen. Du musst nichts einrichten.

• Jedes Konto kann 2 Log-Streams gleichzeitig offen haben.
• Ein Stream schließt nach 5 Minuten ohne neue Ausgabe oder nach insgesamt 30 Minuten. Die Ausgabe sagt das, und ein Knopf verbindet neu.

Neustart, Pausieren, Fortsetzen und Löschen

• Restart startet die App frisch. Nutze das nach dem Ändern von Umgebungsvariablen.
• Pause stoppt die App, behält aber Adresse, Einstellungen und Dateien. Ihr Arbeitsspeicher geht zurück in deinen Tarif.
• Resume startet sie wieder. Das zählt gegen deine Grenzen wie eine neue App und klappt nur, wenn in deinem Tarif Platz ist.
• Delete verlangt, dass du den Namen der App eintippst. Hat sie eine Datenbank, entscheidest du, ob sie bleibt oder gelöscht wird. Die Dateien der App auf der Festplatte werden gelöscht.

Activity und frühere Versionen

Der Tab Activity listet alles, was mit der App passiert ist, das Neueste zuerst und nach Tagen gruppiert: Builds, Versionen, die online gingen, Neustarts, Einschlafen und Aufwachen, Stopps, geänderte Einstellungen und Domains. Die Version, die gerade läuft, steht oben. Die Filter Everything, Versions, Problems und Changes grenzen die Liste ein. Changes zeigt jede Änderung daran, wie die App gebaut oder gestartet wird, und sagt, wer sie gemacht hat und warum. Einstellungen stehen dort nur mit Namen, nie mit ihren Werten.

Jede der letzten 10 Versionen, die online waren, hat einen Knopf "Put this version back" (diese Version zurückholen). Das Build-Log einer Version öffnet sich direkt dort.

Was Besucher sehen, wenn die App nicht läuft

Läuft hinter der Adresse keine App, sehen Besucher eine Seite von blitz.cloud, die sagt, warum: Die App schläft, ist pausiert (und von wem), startet gerade, wurde nach Abstürzen gestoppt oder wird gebaut. Bei einer schlafenden App kommt es selten so weit: Der erste Besuch wartet, bis sie aufgewacht ist, und bekommt dann die Antwort der App selbst, auch bei Formularen. Die Aufwach-Seite erscheint nur, wenn das Aufwachen länger als etwa fünf Sekunden dauert.

Fehlerseiten, die die App selbst schickt, etwa ihre eigene 500 oder 503, kommen bei Besuchern genau so an, wie die App sie geschrieben hat. Soll auch dann unsere Seite erscheinen, schalte im Tab Settings der App "Our page for its errors" ein. Bei einer API lässt du es aus, weil Programme, die sie aufrufen, ihre eigenen Antworten erwarten.

Mails, wenn etwas passiert

Wir schicken dir eine Mail, wenn eine neue Version fehlschlägt oder online geht, wenn wir eine App stoppen, wenn eine Wiederherstellung fertig ist und nach einem nächtlichen Update. Jede davon kannst du unter Settings > Notifications abschalten, oder mit einem Klick direkt in der Mail. Mails zu Konto, Sicherheit und Abrechnung kommen immer.

Automatische Neustarts

Apps aus dem App Store haben einen Health Check, der weiß, was "funktioniert" für diese App bedeutet, und werden neu gestartet, wenn sie nicht mehr antworten. Apps aus deinem eigenen Docker-Image werden nicht neu gestartet, wenn sie nicht mehr antworten, nur wenn sie abstürzen.

Eine App, die abstürzt, wird jedes Mal wieder gestartet, mit immer längeren Pausen dazwischen. Nach 15 Neustarts stoppen wir sie, zeigen Stopped an und schicken dir eine Mail.

Liegt es an deiner App oder an blitz.cloud?

Wenn mehrere deiner Apps auf einmal nicht mehr antworten oder das Dashboard nicht lädt, schau auf status.blitz.cloud, bevor du etwas änderst. Dort steht, ob ein Teil von blitz.cloud gerade ein Problem hat. Die Seite läuft auf einem eigenen Server außerhalb der Plattform und antwortet deshalb auch dann, wenn blitz.cloud es nicht tut.

Kommst du trotzdem nicht weiter? Schreib an hallo@blitzworks.io und nenn die Adresse deiner App.