--- title: "Geplante Aufgaben: Jobs zu festen Zeiten ausführen | Briks" url: https://briks.dev/de/docs/crons description: "Geplante Aufgaben auf Ihrer Website zu festen Zeiten: Morgenübersicht, wöchentliches Aufräumen. Zeitplan schreiben, Läufe lesen, Fehler beheben, Plan-Limits." last_updated: 2026-10-08 --- # Geplante Aufgaben: Jobs zu festen Zeiten ausführen Eine geplante Aufgabe führt zu festen Zeiten etwas auf Ihrer Website aus, ohne dass jemand einen Knopf drückt: jeden Morgen eine Zusammenfassung, jeden Sonntagabend eine Aufräumrunde. Sie finden sie in den **Settings** des Projekts unter **Scheduled tasks**. Diese Seite zeigt, wie Sie eine einrichten, ihre Läufe lesen und eine fehlerhafte beheben. 8 Minuten Lesezeit Am 8. Oktober 2026 mit dem Studio abgeglichen ## Was eine geplante Aufgabe tut Eine geplante Aufgabe ist ein Aufruf, den Briks nach einem Zeitplan ausführt. Sie ruft entweder eine **Route** auf Ihrer Website auf (eine Adresse unter `/api/`, die Code ausführt, statt eine Seite zu zeigen) oder eine andere öffentliche https-Adresse, etwa einen Dienst, den Sie nutzen. Die Adresse erledigt die Arbeit. Briks ruft pünktlich auf und hält fest, was zurückkam. Eine Aufgabe braucht also etwas, das sie aufrufen kann. Hat Ihre Website noch keine Route für die Aufgabe, bitten Sie zuerst im Studio darum und richten die Aufgabe dann darauf. Solange es keine Aufgaben gibt, steht auf der Seite **No scheduled tasks** samt den üblichen Aufgaben: eine tägliche Zusammenfassung senden, alte Datensätze aufräumen oder mit einem anderen Dienst abgleichen. Aufgaben laufen, egal ob die Website veröffentlicht ist, zu den von Ihnen festgelegten Zeiten und in der von Ihnen gewählten Zeitzone. Der Bereich hat drei Ansichten: **Tasks**, **Runs** und **Settings**. Wo 1. Projects 2. Your project 3. Settings 4. Scheduled tasks ## Grenzen in jedem Plan | Plan | Geplante Aufgaben pro Projekt | Aufrufe pro Tag und Projekt | | --- | --- | --- | | Free | 1 | 2,000 | | Starter | 5 | 5.000 | | Pro | 10 | 10,000 | | Studio | 25 | 50.000 | | Agency | 50 | 100.000 | Die Aufrufe pro Tag teilen sich Aufgabenläufe und Zustellversuche von Webhooks, und der Tag beginnt um Mitternacht UTC. Die Ansicht **Tasks** zeigt, wo Sie stehen, etwa 2 von 5 in Ihrem Plan, und **Add task** ist ausgegraut, sobald Sie das Limit erreichen. Daneben erscheint dann ein Link **Get more**, der das Upgrade-Fenster öffnet; es nennt den kleinsten Plan mit Platz für eine weitere Aufgabe. Ein Lauf, der die Aufrufe des Tages überschreiten würde, wird als **Skipped** markiert. Die Pläne vergleichen Sie unter [Abrechnung](https://briks.dev/de/docs/billing). Ein sinnvolles Intervall wählen Eine Aufgabe, die jede Minute läuft, macht allein 1,440 Aufrufe am Tag. Im Free-Tarif mit 2,000 Aufrufen am Tag bleibt dann wenig Platz für alles andere. Alle 5 oder 15 Minuten reicht für die meisten Aufgaben, und einmal am Tag genügt für Zusammenfassungen. ## Geplante Aufgabe hinzufügen 1. Auf Add task klicken Wo: Settings, Scheduled tasks Der Dialog **Add a scheduled task** öffnet sich. Editors, Admins und Owners können Aufgaben hinzufügen. 2. Benennen Sie es Wo: Add a scheduled task Geben Sie einen kurzen Namen, den Sie in der Liste der Läufe wiedererkennen, etwa `Daily digest`. Bis zu 60 Zeichen. 3. Zeitplan festlegen Wo: Add a scheduled task Geben Sie unter **Schedule** einen Zeitplan ein oder drücken Sie eine der Schaltflächen darunter. Der nächste Abschnitt erklärt das Format. 4. Zeitzone wählen Wo: Add a scheduled task **Time zone** beginnt mit Ihrer eigenen. Ein Feld darunter zeigt den Zeitplan in Worten und die nächsten fünf Zeitpunkte, zu denen er dort läuft, damit Sie ihn vor dem Speichern prüfen können. 5. Sagen Sie, wie es heißt Wo: Add a scheduled task Wählen Sie unter **What it calls** die Option **A route on this site** und geben Sie den Pfad ein (er beginnt mit `/api/`), oder **Another address** und geben Sie eine vollständige https-Adresse ein. Bei einer Route zeigt der Hinweis unter dem Feld die vollständige Adresse, die aufgerufen wird. 6. POST oder GET wählen Wo: Add a scheduled task **POST** sendet mit dem Aufruf eine kurze Nachricht, wie sie die meisten für eine Aufgabe gebauten Routen erwarten. **GET** fragt nur die Adresse ab. Wenn Sie unsicher sind, lassen Sie POST eingestellt. 7. Speichern Wo: Add a scheduled task Drücken Sie **Add task**. Die Aufgabe wird erst gespeichert, wenn der Scheduler sie übernommen hat, jede Aufgabe in der Liste ist also eine, die auch läuft. ## Einen Zeitplan schreiben Ein Zeitplan besteht aus fünf durch Leerzeichen getrennten Werten: Minute, Stunde, Tag des Monats, Monat und Wochentag. Ein `*` bedeutet jeweils alle. Wenn sich Ihre Eingabe nicht lesen lässt, sagt das Feld, was nicht stimmt, zum Beispiel welcher Wert außerhalb des Bereichs liegt. | Sie möchten | Typ | Die Vorschau sagt | | --- | --- | --- | | Jeden Morgen um 7 Uhr | `0 7 * * *` | Jeden Tag um 07:00 | | Werktags um halb sieben abends | `30 18 * * 1-5` | Jeden Werktag um 18:30 | | Alle 15 Minuten | `*/15 * * * *` | Alle 15 Minuten | | Alle zwei Stunden, zur vollen Stunde | `0 */2 * * *` | Alle 2 Stunden, zur vollen Stunde | | Sonntagabend um 11 | `0 23 * * 0` | Jeden Sonntag um 23:00 Uhr | | Am 1. jedes Monats um 6 Uhr morgens | `0 6 1 * *` | Am 1. jedes Monats um 06:00 Uhr | Die Wochentage reichen von 0 (Sonntag) bis 6 (Samstag), und 7 ist ebenfalls Sonntag. Sie können auch Namen wie `mon` oder `jan`, Listen wie `1,3,5`, Bereiche wie `1-5` und Schritte wie `*/10` schreiben. Auch Kurzformen funktionieren: `@hourly`, `@daily`, `@weekly`, `@monthly` und `@yearly`. Die Schaltflächen unter dem Feld füllen es für Sie aus: **Every 5 minutes**, **Every hour**, **Every day at 09:00**, **Mondays at 09:00** und **First of the month**. Zwei Details Wenn Sie sowohl den Tag des Monats als auch den Wochentag einschränken, läuft die Aufgabe an jedem Tag, der einem von beiden entspricht. Und bei der Zeitumstellung läuft eine Zeit, die doppelt vorkommt, einmal, während eine Zeit, die die Uhr überspringt, direkt nach der Umstellung läuft, sodass eine tägliche Aufgabe um 02:30 nie ausfällt. ## Was jeder Aufruf enthält Eine Aufgabe wartet bis zu 30 Sekunden auf eine Antwort. Jeder Aufruf trägt den `user-agent` `Briks-Cron/1.0` und einen `x-briks-cron`-Header mit der ID der Aufgabe, damit die Route erkennt, woher der Aufruf kommt. Ein POST-Aufruf sendet außerdem eine kurze JSON-Nachricht (JSON ist ein einfaches Textformat, das Programme lesen), die die Aufgabe benennt: Der Body eines POST-Aufrufs > `{"cron":{"id":"…","name":"Daily digest"},"trigger":"schedule","scheduledFor":"2026-10-09T06:00:00.000Z"}` `trigger` ist `manual`, wenn jemand auf **Run now** geklickt hat, und dann ist `scheduledFor` gleich `null`. Briks ruft keine Adresse in einem privaten Netzwerk, keine als Zahlen geschriebene Adresse und keine eigene Adresse auf und folgt keinen Weiterleitungen, geben Sie daher die endgültige Adresse an. Aufrufe einer Route Ihrer Website gehen an deren `briks.live`-Adresse und folgen ihr, wenn Sie diese Adresse ändern. ## Runs und was jeder Status bedeutet Wo 1. Projects 2. Your project 3. Settings 4. Scheduled tasks 5. Runs **Runs** listet jeden Lauf der letzten dreißig Tage auf, den neuesten zuerst, ob geplant oder von Hand gestartet. Ein von Hand gestarteter Lauf trägt den Hinweis **By hand**. Bei mehr als einer Aufgabe wählen Sie im Feld über der Liste eine aus und drücken **Show**. Klicken Sie auf einen Lauf, um die aufgerufene Methode und Adresse, einen eventuellen Fehler und den Anfang der Antwort der Adresse zu sehen. | Status | Was passiert ist | | --- | --- | | **Succeeded** | Die Adresse antwortete mit einem 2xx-Status, dem Code des Webs für Erfolg. | | **Failed** | Alles andere: ein anderer Status (404 bedeutet nicht gefunden, 500 bedeutet, dass der Code dahinter fehlgeschlagen ist), keine Antwort innerhalb von 30 Sekunden, eine Weiterleitung oder eine Adresse, die nicht erreichbar war. | | **Skipped** | Die Aufrufe des Projekts für heute sind aufgebraucht. Der Lauf meldet: Today's calls for this project are used up. Läufe starten nach Mitternacht (UTC) wieder. | Die Ansicht **Tasks** zeigt dasselbe auf einen Blick: **Next** mit der Zeit des kommenden Laufs, **Last** mit dem letzten Status oder **Not run yet**. ## Wenn ein Lauf fehlschlägt Eine fehlgeschlagene Ausführung wird protokolliert und nicht wiederholt. Die nächste folgt zur üblichen Zeit. Auch Ausführungen, die verpasst wurden, während nichts sie ausführen konnte, werden nicht nachgeholt: Die Aufgabe läuft einmal und macht dann normal weiter. Haben Sie die Ursache behoben, öffnen Sie die drei Punkte der Aufgabe und wählen **Run now**. Das Ergebnis erscheint sofort, zum Beispiel: Daily digest ran: the address answered 200 in 312 ms. Sie können eine Aufgabe bis zu 20 Mal pro Stunde von Hand ausführen, und jeder Lauf zählt zu den Aufrufen des Tages. | Was der Lauf meldet | Was zu tun ist | | --- | --- | | antwortete mit 404 | Unter diesem Pfad gibt es keine Route. Prüfen Sie die Schreibweise und ob die Version mit der Route veröffentlicht wurde. | | 500 beantwortet | Die Route selbst ist fehlgeschlagen. Öffnen Sie [Logs](https://briks.dev/de/docs/logs), wählen Sie **Requests** und suchen Sie nach dem Pfad, um den Fehler zu lesen. | | Keine Antwort innerhalb von 30 Sekunden. | Der Auftrag dauert auf einmal zu lange. Fragen Sie im Studio nach einem Weg, pro Aufruf weniger zu erledigen und ihn öfter auszuführen. | | Weiterleitungen werden nicht verfolgt: Verwenden Sie die endgültige Adresse. | Öffnen Sie die Adresse in einem Browser, kopieren Sie das Ziel, auf dem sie landet, und ändern Sie die Aufgabe auf dieses Ziel. | | Diese Adresse verweist auf ein privates Netzwerk und kann nicht aufgerufen werden. | Verwenden Sie eine öffentliche Adresse. Briks greift nie auf private Netzwerke zu. | Aufträge wiederholbar machen Jeder, der die Adresse einer Route kennt, kann sie aufrufen, und beim Testen drücken Sie **Run now**. Bitten Sie um Routen, die bei doppelter Ausführung keinen Schaden anrichten: Löschen Sie Datensätze, die älter als 90 Tage sind, statt der ältesten 50. ## Pausieren, ändern oder löschen Der Schalter neben jeder Aufgabe pausiert sie (es erscheint der Hinweis **Paused**) und startet sie wieder. In den drei Punkten öffnet **Change** dasselbe Formular mit dem Titel **Change task**, und **Delete** stoppt die Aufgabe und entfernt ihren Verlauf. Für all das brauchen Sie Bearbeitungsrechte. Wo 1. Projects 2. Your project 3. Settings 4. Scheduled tasks 5. Settings Die Ansicht **Settings** hat **Download JSON**, eine Datei mit Name, Zeitplan, Zeitzone und Aufrufziel jeder Aufgabe. Ihr Gefahrenbereich enthält **Clear history** (die Aufgaben laufen weiter) und **Delete all** (zur Bestätigung geben Sie den Namen des Projekts ein). Beides ist Owners und Admins vorbehalten. ## Praxisbeispiele Im Studio gefragt Eine tägliche Zusammenfassung für eine Physiotherapiepraxis > Füge eine Route unter /api/daily-summary hinzu, die mir die Terminanfragen von gestern in einer Nachricht per E-Mail sendet. Nachdem die Änderung veröffentlicht ist, legt die Klinik eine geplante Aufgabe namens `Daily summary` an, mit dem Zeitplan `0 7 * * *` und der Zeitzone Europe/London, die POST `/api/daily-summary` aufruft. Jeden Morgen um sieben kommt die Zusammenfassung an. Die Zusammenfassung wird über die eigene E-Mail der Website verschickt, die ausgeschaltet ist, bis Sie sie einschalten. Wie das geht und wie hoch das monatliche Kontingent ist, steht unter [E-Mail der Website](https://briks.dev/de/docs/site-email). Im Studio gefragt Alte Datensätze für eine Nachhilfeagentur aufräumen > Füge eine Route unter /api/tidy-enquiries hinzu, die Anfragen löscht, die älter als 90 Tage sind. Eine Aufgabe namens `Tidy enquiries` führt sie mit `0 23 * * 0` aus, jeden Sonntag um 23:00 Uhr. Am Montag zeigt **Runs** den Status **Succeeded**, und wenn Sie den Lauf öffnen, sehen Sie, was die Route zurückgemeldet hat. Bevor eine solche Bereinigung zum ersten Mal läuft, speichern Sie in den Einstellungen des Tabs Database einen Wiederherstellungspunkt. Löscht die Route mehr als vorgesehen, können Sie zurückgehen. Siehe [Backups](https://briks.dev/de/docs/backups). ## Als Nächstes lesen - [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) - [Daten und Automatisierung **Logs** Build-Protokoll und Anfragen des letzten Tages lesen, nach Level oder Status filtern, ein defektes Formular, einen defekten Job, eine langsame Seite finden.](https://briks.dev/de/docs/logs) - [Die Funktionen Ihrer Website **Website-E-Mail** Senden Sie Bestätigungen und Antworten von der eigenen Adresse auf emails.briks.live, wählen Sie das Antwortziel und verfolgen Sie Ihr Monatskontingent.](https://briks.dev/de/docs/site-email) - [Daten und Automatisierung **Database** Sehen, was Ihre Website speichert, Datensätze von Hand bearbeiten und hinzufügen, Sammlungen als JSON oder CSV laden, wer was darf und welche Grenzen gelten.](https://briks.dev/de/docs/database) 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.