Viele Laravel-Projekte laufen im Alltag ruhig vor sich hin. Bis plötzlich ein Kunde fragt: „Warum kommen keine Bestellmails mehr an?“ Oder das Team merkt am Montagmorgen, dass die Queue seit Freitagabend beleidigt in der Ecke sitzt.
Für genau solche Fälle lohnt sich eine kleine interne Statusseite. Kein großes Enterprise-Monitoring, kein Dashboard mit 47 Diagrammen, sondern eine einfache Übersicht: Datenbank erreichbar? Cache funktioniert? Queue arbeitet? Storage beschreibbar? Mail-Konfiguration vorhanden?
In diesem Tutorial bauen wir eine pragmatische Statusseite für Laravel, die besonders für Agenturen, Selbstständige und kleinere Unternehmen nützlich ist. Sie ersetzt kein professionelles Monitoring, aber sie hilft enorm bei Übergaben, Wartung und Support. Und sie ist deutlich besser als „Ich klick mal kurz überall rein“.
Was wir bauen
Am Ende hast du eine geschützte URL wie /internal/status. Dort siehst du eine kompakte Liste mit Prüfungen:
- Datenbankverbindung
- Cache-Schreibtest
- Storage-Schreibtest
- Queue-Konfiguration
- Mail-Grundkonfiguration
- Laravel-Umgebung und Debug-Status
- Optional: Projektversion oder letzter Deployment-Zeitpunkt
Wichtig: Die Seite ist nicht öffentlich gedacht. Sie soll deinem Team, deiner Agentur oder ausgewählten Ansprechpartnern helfen. Sicherheitsdetails gehören nicht auf eine frei zugängliche URL.
Schritt 1: Route anlegen
Lege zuerst eine geschützte Route an. Für ein internes Werkzeug reicht in vielen Projekten ein Middleware-Schutz über Login und Berechtigung. Wenn du bereits ein Admin-Panel hast, kannst du die Seite dort einhängen.
Beispiel: In routes/web.php legst du eine Route wie /internal/status an und verweist auf einen Controller, zum Beispiel StatusController.
Sinngemäß:
Route: GET /internal/status → StatusController@index
Nutze mindestens eine Auth-Middleware. Noch besser ist eine zusätzliche Rollenprüfung, etwa nur für Admins oder interne Nutzer. Eine Statusseite ohne Schutz ist wie ein Schaufenster mit deinem Server-Innenleben. Spannend, aber keine gute Idee.
Schritt 2: Controller erstellen
Erstelle einen Controller, der mehrere Checks sammelt und an eine View übergibt. Der Controller sollte selbst möglichst schlank bleiben. Die eigentliche Prüflogik lagerst du besser in eine eigene Klasse aus, zum Beispiel App\Support\SystemStatus.
Warum? Weil du die Checks später leichter erweitern, testen oder auch per Artisan Command ausführen kannst. Das ist einer dieser kleinen Strukturentscheidungen, die später Zeit sparen.
Der Controller macht dann im Kern nur drei Dinge:
- Status-Service aufrufen
- Ergebnisse einsammeln
- View rendern
Schritt 3: Status-Service bauen
Jetzt wird es praktisch. Erstelle eine Klasse, zum Beispiel app/Support/SystemStatus.php. Diese Klasse enthält Methoden für die einzelnen Checks.
Ein Ergebnis sollte immer ähnlich aufgebaut sein:
- name: Verständlicher Name, zum Beispiel „Datenbank“
- status: ok, warning oder error
- message: Kurze Erklärung für Menschen
Das klingt banal, ist aber wichtig. Eine gute Statusseite soll nicht nur Entwicklern helfen. Auch Projektmanager, Kundensupport oder technisch interessierte Kunden sollten verstehen, ob etwas kritisch ist.
Check 1: Datenbankverbindung
Für den Datenbankcheck reicht häufig eine einfache Abfrage wie select 1. Wenn diese fehlschlägt, ist klar: Die Anwendung kann nicht sauber mit der Datenbank sprechen.
Die Meldung sollte nicht den kompletten Datenbankfehler ausgeben. Intern im Log ja, auf der Statusseite lieber kurz und sauber: „Datenbank nicht erreichbar“.
Check 2: Cache-Schreibtest
Viele Laravel-Anwendungen verlassen sich auf Cache. Deshalb ist ein kleiner Schreib- und Lesetest sinnvoll:
- Testwert in den Cache schreiben
- Wert wieder auslesen
- Prüfen, ob er übereinstimmt
- Testwert löschen
Wenn das nicht funktioniert, ist das oft kein kompletter Totalausfall, aber ein klarer Warnhinweis. Gerade bei Performance-Problemen kann ein defekter oder falsch konfigurierter Cache ein sehr nerviger Kandidat sein.
Check 3: Storage beschreibbar?
Viele Projekte speichern Uploads, Exporte, Rechnungen oder temporäre Dateien. Prüfe deshalb, ob Laravel in den vorgesehenen Storage schreiben kann.
Der Ablauf ist ähnlich wie beim Cache:
- Kleine Testdatei schreiben
- Existenz prüfen
- Datei wieder löschen
Bitte nicht in produktive Kundenordner schreiben. Nutze einen klaren internen Pfad wie health-check/status-test.txt. Das ist aufgeräumt und später leicht zu finden.
Check 4: Queue-Konfiguration prüfen
Viele geschäftskritische Dinge laufen in Laravel-Projekten über Queues: E-Mails, Exporte, Webhooks, Rechnungsprozesse, Benachrichtigungen. Wenn die Queue steht, sieht die Webseite manchmal noch gesund aus, aber im Hintergrund bleibt Arbeit liegen.
Ein einfacher erster Check ist die Konfiguration:
- Welcher Queue-Treiber ist aktiv?
- Ist in Produktion versehentlich sync gesetzt?
- Gibt es Hinweise auf fehlende Worker?
Der Treiber sync ist lokal praktisch, in produktiven Projekten aber oft kein guter Standart. Wenn du Jobs wirklich im Hintergrund abarbeiten möchtest, solltest du einen passenden Queue-Treiber und einen laufenden Worker verwenden.
Die Statusseite kann hier eine Warnung anzeigen: „Queue läuft synchron – für Produktion prüfen.“ Das ist kein automatischer Weltuntergang, aber ein sinnvoller Hinweis.
Check 5: Mail-Grundkonfiguration
Du musst auf der Statusseite keine Testmail verschicken. Das kann schnell nerven, vor allem wenn jemand die Seite fünfmal aktualisiert. Prüfe lieber zuerst die Grundkonfiguration:
- Ist ein Mailer gesetzt?
- Ist eine Absenderadresse vorhanden?
- Ist in Produktion aus Versehen ein Log- oder Array-Mailer aktiv?
Auch hier gilt: keine Passwörter, Tokens oder SMTP-Details anzeigen. Nur verständliche Hinweise.
Schritt 4: View schlicht halten
Die View braucht kein Design-Feuerwerk. Eine einfache Liste oder Tabelle reicht völlig. Nutze klare Farben oder Labels:
- OK: Grün oder neutral
- Warnung: Gelb
- Fehler: Rot
Wichtig ist die Sprache. „Cache write failed“ ist für Entwickler okay. Besser für den Alltag ist: „Cache kann nicht beschrieben werden. Das kann die Geschwindigkeit und einzelne Funktionen beeinträchtigen.“
Wenn du für Kunden arbeitest, schreibe die Meldungen so, dass sie im Support verwendbar sind. Niemand möchte im Krisenfall erst eine Fehlermeldung übersetzen, während der Kaffee kalt wird.
Schritt 5: Sicherheit nicht vergessen
Eine interne Statusseite kann unbeabsichtigt sensible Informationen verraten. Deshalb solltest du ein paar Regeln einhalten:
- Nur für eingeloggte und berechtigte Nutzer zugänglich machen
- Keine Passwörter, Tokens, API-Keys oder vollständigen Serverpfade anzeigen
- Fehlerdetails ins Laravel-Log schreiben, nicht komplett in die Oberfläche
- In Produktion APP_DEBUG=false prüfen und als Warnung anzeigen, falls es anders ist
- Optional zusätzlich per IP, VPN oder Basic Auth absichern
Gerade der Debug-Status ist ein guter Pflichtcheck. Wenn APP_DEBUG in Produktion aktiv ist, sollte die Statusseite nicht höflich nicken, sondern deutlich warnen.
Schritt 6: Optional einen Artisan Command ergänzen
Wenn du die Checks wiederverwenden möchtest, baue zusätzlich einen Artisan Command. Dann kannst du den Status auch im Terminal prüfen, etwa bei Deployments oder Wartungsfenstern.
Praktischer Workflow:
- Deployment durchführen
- php artisan app:status ausführen
- Bei Fehlern Deployment stoppen oder manuell prüfen
- Erst danach Projekt an Kunde oder Team freigeben
Das ist besonders nützlich für Agenturen, die mehrere Laravel-Projekte betreuen. Ein gleichbleibender Prüfablauf reduziert Flüchtigkeitsfehler. Und ja, genau diese kleinen Dinge unterscheiden „läuft schon irgendwie“ von professionellem Betrieb.
Schritt 7: Optional Benachrichtigung einbauen
Die Statusseite ist reaktiv: Jemand schaut drauf und sieht den Zustand. Wenn du einen Schritt weitergehen willst, kannst du kritische Checks regelmäßig ausführen und bei Fehlern eine Benachrichtigung senden.
Zum Beispiel:
- Laravel Scheduler ruft alle paar Minuten oder stündlich einen Status-Command auf
- Bei Fehlerstatus wird eine Mail, Slack- oder Teams-Nachricht gesendet
- Warnungen werden gesammelt, aber nicht sofort eskaliert
Halte das am Anfang lieber simpel. Zu viele Benachrichtigungen führen schnell zur Alarm-Müdigkeit. Dann ignoriert man irgendwann alles – auch den einen Alarm, der wirklich wichtig gewesen wäre. Klassiker.
Kurzer Hinweis zu Admin-Panels und Filament
Wenn du deine interne Statusseite lieber in einem Admin-Panel pflegen möchtest, ist Filament für viele Laravel-Projekte eine naheliegende Option. Interessant in dem Zusammenhang: Laravel News berichtete am 26.06.2026, dass das Filament-Team Performance-Upgrades für First-Party-Filament-Pakete gestartet hat und Nutzer um Mithilfe beim Testen bittet: Help make Filament faster!
Für dieses Tutorial brauchst du Filament nicht. Aber wenn du ohnehin ein internes Admin-Panel betreibst, kann eine Statusseite dort gut aufgehoben sein.
Welche Checks lohnen sich zusätzlich?
Je nach Projekt kannst du die Statusseite erweitern. Sinnvoll sind zum Beispiel:
- Externe APIs: Ist der Zahlungsanbieter erreichbar?
- Webhooks: Wann kam der letzte erfolgreiche Webhook an?
- Letzter Import: Wann wurden Produktdaten zuletzt aktualisiert?
- Letztes Backup: Gibt es ein aktuelles Backup? Achtung: nur Status anzeigen, keine Backup-Pfade oder Zugangsdaten.
- Speicherplatz: Wird der Serverplatz knapp?
- SSL-Zertifikat: Läuft es bald ab?
Aber übertreibe es nicht direkt. Eine Statusseite mit 6 guten Checks ist besser als ein halbfertiges Kontrollzentrum, das niemand versteht.
Praxis-Tipp für Kundenprojekte
Wenn du als Agentur oder Freelancer arbeitest, kannst du die Statusseite in deine Projektübergabe aufnehmen. Erkläre dem Kunden kurz:
- Was wird geprüft?
- Was bedeutet OK, Warnung und Fehler?
- Wann soll der Kunde dich kontaktieren?
- Welche Meldungen sind nur interne Hinweise?
Das schafft Vertrauen, weil Betrieb sichtbar wird. Gleichzeitig reduzierst du Support-Rückfragen wie „Ist die Webseite kaputt oder nur die Mail?“ Manchmal ist die Antwort trotzdem „kommt drauf an“, aber wenigstens schaust du dann an die richtige Stelle.
Fazit: Kleine Statusseite, große Wirkung
Eine Laravel-Statusseite ist kein Ersatz für Monitoring, Logging oder saubere Deployment-Prozesse. Aber sie ist ein sehr nützlicher Baustein für den Alltag. Sie hilft bei Support, Übergaben, Wartung und Fehleranalyse.
Der größte Vorteil: Du machst unsichtbare technische Abhängigkeiten sichtbar. Datenbank, Cache, Queue, Storage und Mail sind für viele Geschäftsprozesse entscheidend. Wenn dort etwas hakt, sollte dein Team das schnell erkennen können.
Starte klein: fünf Checks, geschützte Route, verständliche Meldungen. Danach kannst du erweitern. Nicht perfekt ist hier völlig in Ordnung – hauptsache nützlich.
