--- title: "Logs: Builds und die Anfragen Ihrer Website | Briks" url: https://briks.dev/de/docs/logs description: "Build-Protokoll und Anfragen des letzten Tages lesen, nach Level oder Status filtern, ein defektes Formular, einen defekten Job, eine langsame Seite finden." last_updated: 2026-10-08 --- # Logs: Builds und die Anfragen Ihrer Website Logs zeigen, was wann geschehen ist: jeden Build und jede Veröffentlichung im Projekt sowie jede Anfrage, die den eigenen Code Ihrer Website im letzten Tag ausgeführt hat. Damit finden Sie heraus, warum ein Formular, eine geplante Aufgabe oder eine Seite sich nicht richtig verhält. 5 Minuten Lesezeit Am 8. Oktober 2026 mit dem Studio abgeglichen ## Zwei Arten von Protokollen Wo 1. Projects 2. Your project 3. Settings 4. Logs | Ansehen | Was angezeigt wird | Wie weit zurück | | --- | --- | --- | | **Builds** | Jeder Build, jede Änderung und jede Veröffentlichung in diesem Projekt sowie die Schritte, die sie durchlaufen haben. | Die letzten 40 | | **Requests** | Die Anfragen und Fehler der Website, die neuesten zuerst. | Die letzten 24 Stunden, jeweils bis zu 100 | Geplante Aufgaben und Webhooks führen eigene Logs, dreißig Tage lang: **Runs** unter [Geplante Aufgaben](https://briks.dev/de/docs/crons) und **Deliveries** unter [Webhooks](https://briks.dev/de/docs/webhooks). Nachrichten, die über Ihre Formulare gesendet wurden, bleiben unter **Settings**, **Forms** gespeichert. ## Builds Jeder Eintrag sagt, was angefragt wurde (in den Worten der Anfrage), wer es angefragt hat, wann und wie lange es dauerte. Wenn keine Person es gestartet hat, steht dort Briks. Rechts steht der Status: | Status | Bedeutung | | --- | --- | | **Waiting** | Wartet hinter anderen Aufgaben. | | **Running** | Ist gerade in Arbeit. | | **Done** | Fertig. | | **Failed** | Es wurde vor dem Ende angehalten. | | **Stopped** | Sie wurde gestoppt, bevor sie fertig war. | Klicken Sie auf einen Eintrag, um seine Schritte zu sehen, jeweils mit der Uhrzeit. Ein fehlgeschlagener Schritt wird rot angezeigt. Ein fehlgeschlagener Eintrag endet mit: It did not finish. Nothing on the live site changed, and no credits were charged for it. Um dieselbe Arbeit live mitzuverfolgen, mit der Vorschau daneben, nutzen Sie das Studio: siehe [Einen Build beobachten](https://briks.dev/de/docs/watching-a-build). ## Anfragen **Requests** zeigt Aufrufe, die den eigenen Code Ihrer Website ausgeführt haben: ihre `/api`-Routen und Seitenaufrufe, während ein A/B-Test die Besucher auf zwei Versionen aufteilt. Normale Seiten, Bilder und Dateien werden unverändert ausgeliefert, deshalb erscheinen sie nicht. Das gilt auch für Nachrichten über ein Kontaktformular, die direkt an Briks gehen und nicht durch den Code Ihrer Website. Jede Zeile zeigt die Zeit, die Methode und den Pfad (GET fragt etwas an, POST sendet etwas), wie lange es in Millisekunden gedauert hat und den Status, mit dem die Website geantwortet hat, oder keine Antwort. Zeilen, die der Code Ihrer Website selbst geschrieben hat, zeigen ihre Nachricht und eine Stufe wie error oder warning. Klicken Sie auf eine Zeile für die vollständige Nachricht, das Datum und die ID der Anfrage. | Status | Was es bedeutet | | --- | --- | | 2xx, etwa 200 | Es hat funktioniert. | | 4xx, etwa 400 oder 404 | Die Anfrage wurde abgewiesen: Es fehlte etwas, oder etwas war falsch, oder unter diesem Pfad existiert nichts. | | 5xx, zum Beispiel 500 | Der Code der Website ist bei der Antwort fehlgeschlagen. | ### Filter | Filter | Auswahl | Nutzen Sie es, um | | --- | --- | --- | | **Search** | Beliebige Wörter: ein Pfad, eine Nachricht, eine Anfragekennung | Eine Route oder einen Fehler finden. | | **Level** | **All levels**, **Errors**, **Warnings** | Nur Probleme anzeigen, die der Code gemeldet hat. | | **Status** | **Any status**, **Succeeded**, **4xx**, **5xx** | Nur abgewiesene oder fehlgeschlagene Anfragen anzeigen. | Legen Sie sie fest und drücken Sie **Show**. Die Adresse der Seite behält sie, sodass Sie eine gefilterte Ansicht als Lesezeichen speichern können. **No requests in the last day** bedeutet, dass in 24 Stunden kein Code der Website lief. Zeigt die Seite **Logs cannot be read right now**, versuchen Sie es in einer Minute erneut. ## Ein fehlerhaftes Formular diagnostizieren 1. Suchen Sie nach dem Eintrag Wo: Settings, Forms Jede Nachricht eines Besuchers wird hier gespeichert, die letzten 100 auf dem Bildschirm. Jede zeigt, wann sie kam und von welcher Seite, dann **emailed**, **not emailed** oder **preview**. 2. Wenn dort Vorschau steht Wo: Settings, Forms Die Website wurde nicht in Produktion veröffentlicht, daher werden Einträge gespeichert, aber nicht per E-Mail verschickt. Siehe [In Produktion veröffentlichen](https://briks.dev/de/docs/publish-to-production). 3. Wenn es heißt, die E-Mail wurde gesendet, aber nichts ankommt Wo: Your inbox Einträge gehen an die Person, die das Projekt erstellt hat, oder an den ersten Owner des Workspace, falls diese Person nicht mehr dabei ist. Prüfen Sie dieses Postfach, auch den Spam-Ordner. 4. Wenn es gar nicht da ist Wo: The live site Die Nachricht hat Briks nie erreicht. Senden Sie selbst eine. Antwortet das Formular, von hier seien zu viele Nachrichten gesendet worden, wurde ein Limit erreicht: bis zu 5 Nachrichten pro Besucher in 10 Minuten und bis zu 300 pro Tag für die Website. 5. Wenn ein anderes Tool es haben soll Wo: Settings, Webhooks, Deliveries Setzen Sie **Status** auf **Failed** und drücken Sie **Show**. Öffnen Sie die Zustellung, um zu lesen, was das andere Tool geantwortet hat, und wählen Sie nach der Korrektur **Send again**. Formulare, die in Ihrer Datenbank speichern Ein Formular, das in Ihrer Datenbank speichert, etwa eine Buchungsanfrage in einer App, führt den eigenen Code Ihrer Website aus. Seine Sendungen erscheinen trotzdem unter **Requests**: Suchen Sie nach seinem Pfad und setzen Sie **Status** auf **5xx**, um die fehlgeschlagenen zu finden. ## Eine fehlgeschlagene geplante Aufgabe untersuchen 1. Den Lauf lesen Wo: Settings, Scheduled tasks, Runs Öffnen Sie den fehlgeschlagenen Lauf. Er zeigt, was die Adresse geantwortet hat, etwa answered 500, und den Anfang der Antwort. 2. Den Fehler finden Wo: Settings, Logs, Requests Wenn die Aufgabe eine Route auf Ihrer Website aufruft, suchen Sie nach deren Pfad, zum Beispiel `/api/daily-summary`, und setzen Sie **Level** auf **Errors**. Die Meldung sagt, was im Code schiefgelaufen ist. 3. Bitten Sie um die Korrektur Wo: Studio Fügen Sie den Fehler in den Studio-Chat ein, zusammen mit einem Satz zur Aufgabe: Die Route für die tägliche Zusammenfassung schlägt jeden Morgen mit diesem Fehler fehl. Siehe [Änderungen vornehmen](https://briks.dev/de/docs/making-changes). 4. Erneut versuchen Wo: Settings, Scheduled tasks Öffnen Sie nach der Veröffentlichung der Korrektur die drei Punkte der Aufgabe und wählen Sie **Run now**. Das Ergebnis erscheint sofort. Ein als **Skipped** markierter Lauf ist nicht fehlgeschlagen: Die Aufrufe des Projekts für den Tag waren aufgebraucht. Die Läufe starten nach Mitternacht UTC wieder. Die Tariflimits stehen auf der Seite [Geplante Aufgaben](https://briks.dev/de/docs/crons). ## Eine langsame Seite diagnostizieren **Requests** misst alles, was den Code Ihrer Website ausführt. Hier sollten Sie nachsehen, wenn sich eine Seite langsam anfühlt, die ihren Inhalt über die Routen der Website lädt. Apps und Dashboards funktionieren meist so. 1. Seite öffnen und die Uhrzeit notieren Wo: The live site Laden Sie die langsame Seite einmal selbst, damit ihre Anfragen zu den neuesten gehören. 2. Die Zeiten lesen Wo: Settings, Logs, Requests Sehen Sie sich die Millisekunden neben jeder Anfrage zu diesem Zeitpunkt an. Dauert eine Route mehrere Sekunden, während andere nur einige hundert Millisekunden brauchen, ist sie der Übeltäter. 3. Eingrenzen Wo: Settings, Logs, Requests Suchen Sie nach dem Pfad dieser Route, um zu sehen, ob sie immer langsam ist oder nur manchmal und ob daneben **Warnings** oder **Errors** erscheinen. 4. Um eine Korrektur bitten Wo: Studio Sagen Sie dem Studio, welche Route langsam ist und wie langsam, samt der Seite, die sie ausliefert. Wenn nichts Langsames erscheint, liegt die Verzögerung nicht im Code Ihrer Website. Seiten, Bilder und Dateien werden unverändert ausgeliefert, achten Sie also darauf, was die Seite enthält, etwa große Bilder oder ein Video, und beschreiben Sie im Studio, was sich langsam anfühlt. ## Praxisbeispiel: Eine Buchungs-App, die nicht mehr speicherte Was der Inhaber bemerkte Ein Hundesalon in Leeds > Seit dem Morgen waren keine neuen Buchungen eingegangen, obwohl das Telefon weiter klingelte und Leute sagten, das Formular tue nichts. Unter **Requests** mit **Status** auf **5xx** wurde jedes `POST /api/bookings` seit 9:12 Uhr mit 500 beantwortet. Die Fehlerzeile daneben besagte, dass ein Pflichtfeld fehlte. Im Studio gefragt > Seit heute Morgen schlägt jede Buchung mit einem 500 auf /api/bookings fehl. Im Protokoll steht, dass das Feld für die Tiergröße fehlt. Wir haben dieses Feld gestern aus dem Formular entfernt. Die Änderung wurde veröffentlicht, und die nächste Buchung unter **Requests** wurde mit 200 beantwortet. ## Als Nächstes lesen - [Daten und Automatisierung **Geplante Aufgaben** Geplante Aufgaben auf Ihrer Website zu festen Zeiten: Morgenübersicht, wöchentliches Aufräumen. Zeitplan schreiben, Läufe lesen, Fehler beheben, Plan-Limits.](https://briks.dev/de/docs/crons) - [Daten und Automatisierung **Webhooks** Signierte Nachricht an ein Tool bei Veröffentlichung, Formularversand oder Datensatzänderung. Payloads, Signaturen, Wiederholungen und Zustellungen erklärt.](https://briks.dev/de/docs/webhooks) - [Die Funktionen Ihrer Website **Formulare** Ein Formular hinzufügen, in der Vorschau testen, jeden Eintrag im Studio finden, in der Produktion per E-Mail erhalten und per Webhook weitergeben.](https://briks.dev/de/docs/forms) - [Hilfe **Fehlerbehebung** Was Sie tun können, wenn in Briks etwas nicht funktioniert: Anmeldung, Credits, Builds und Änderungen, Domains, Formulare, E-Mail, Chatbot, Daten und Teams.](https://briks.dev/de/docs/troubleshooting) Noch nicht weitergekommen? Schreiben Sie an [hello@briks.dev](mailto:hello@briks.dev) mit dem Namen Ihres Projekts und dem, was Sie erwartet haben. Ein Screenshot hilft.