For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /de/docs/modules/schedules.md (or send Accept: text/markdown).
Geplante Tasks
Wiederkehrende Workspace-Arbeit über die Schedule-Actions.
Schritt-für-Schritt für Einsteiger
Voraussetzungen: Lesen Sie die beiden folgenden Einsteigerhandbücher, schließen Sie die lokale Web-Einrichtung ab und öffnen Sie dieses Monorepo im Stammverzeichnis in Ihrem Editor. Webeinstellungen gehören in apps/web/.env.local; Next.js liest das Stammverzeichnis .env nicht. /dashboard im Standard-Fake-Modus ist eine Demo ohne Datenbank; /auth benötigt eine migrierte Datenbank.
Kurze Begriffe: Ein Arbeitsbereich umfasst die einzelnen Benutzer, Daten und Einstellungen eines Teams. Der Server ist das vertrauenswürdige Backend; Halten Sie Anbieterschlüssel aus Browser- und Telefoncodes fern. Eine Migration ist eine versionierte Datenbankänderung, die Tabellen erstellt oder aktualisiert. Ein KI-Modell ist der Motor, der antwortet; Der Modellkatalog ist die Liste der verfügbaren Modell-IDs und Preise des Servers. Ein Anbieter ist ein externer Dienst wie ein KI-, E-Mail- oder Abrechnungsdienst. Eine Berechtigung ist eine Bewilligung, die einem Arbeitsbereich die Nutzung einer Funktion ermöglicht. Ein Webhook ist eine Nachricht, die ein Dienst an den URL eines anderen Dienstes sendet.
1. Öffnen Sie Settings → Developers und verwenden Sie die Zeitpläne-Steuerelemente, um einen Testauftrag mit einer UTC-Laufzeit zu erstellen.
2. Lassen Sie die App laufen und stellen Sie der App und dem Terminal denselben Nur-Server-SCHEDULER_TICK_SECRET zur Verfügung. Führen Sie den folgenden Befehl im Repository-Stammverzeichnis aus.
3. Bestätigen Sie, dass die Fälligkeitszeit vorverlegt wird und der Auftrag seinen eigenen Status erreicht. Wenn nichts ausgeführt wird, überprüfen Sie die UTC-Zeit, den Scheduler-Anbieter und die Serverprotokolle. Füge das Geheimnis niemals in den Chat ein.
Beginnen Sie für benutzerdefinierten Code mit dem bereitgestellten prompts/README.md und kopieren Sie die nächstgelegene Eingabeaufforderung: prompts/new-app-screen.md für einen App-Bildschirm oder prompts/new-landing-page.md für eine öffentliche Seite. Geben Sie Ihrem Programmieragenten für Server-, Datenbank- oder Anbieterarbeiten die Aufgabe dieses Handbuchs und bitten Sie ihn, AGENTS.md, .ai/PROJECT_CONTEXT.md und passende .ai/-Spiegel zu lesen; Überprüfen Sie die hier genannten genauen Quelldateien. Listen Sie Dateien auf und prüfen Sie sie vor der Bearbeitung. Bewahren Sie den Arbeitsbereichseigentum und die Nur-Server-Geheimnisse. und zeige dir den Unterschied. Teilen Sie ihm das gewünschte Verhalten, Eingabe- und Ausgabefelder, zulässige Rollen, erwartete Erfolge und Fehler sowie das Testkonto, den Anbieter oder das Gerät mit. Beispielwerte verwenden; Fügen Sie niemals ein echtes Geheimnis ein.
corepack pnpm jobs:tickWiederkehrende Arbeit in der Datenbank speichern
Die Zeitplanung in den Einstellungen speichert Jobtyp und Cron-Regel in Workspace-spezifischen job_schedule-Zeilen. Cron-Felder werden in UTC ausgewertet. createDrizzleJobScheduler.claimDueSchedules beansprucht fällige Zeilen mit FOR UPDATE SKIP LOCKED, rückt ihren nächsten Lauf vor und stellt anschließend Handler-Aufgaben ein.
Der allgemeine JobRunner verspricht enqueue, status und cancel. Wiederholung gehört zu den Scheduler-Zeilen; die Trigger.dev-Workflow-Semantik bleibt ausdrücklich festgelegt.
Scheduler-Ticks auslösen
Legen Sie einen Nur-Server-SCHEDULER_TICK_SECRET fest, um POST /api/internal/scheduler-tick zu aktivieren. corepack pnpm jobs:tick nennt es für dev/CI; Fehlende Konfiguration gibt 404 zurück. Unter JOB_PROVIDER=trigger steuert der bereitgestellte scheduler.tick-Cron den Scheduler.
# Against a running local app, with SCHEDULER_TICK_SECRET configured:
corepack pnpm jobs:tickAnspruch und Ausführung getrennt prüfen
Testen Sie überlappende Ticks, Fälligkeit und Nichtfälligkeit, deaktivierte Zeilen, Handler-Fehler, Abbruch und den Zeitplan eines anderen Workspace. Prüfen Sie das Beanspruchen und Weiterschalten getrennt vom Jobabschluss; eine beanspruchte Zeile belegt keinen abgeschlossenen Job.
Einrichtung und Konfiguration
Geplante Arbeit — Digests, Cleanups, Renewals — läuft über schedule-actions statt Ad-hoc-Timer: listWorkspaceSchedules, upsertScheduleAction und removeScheduleAction verwalten die cron-getriebenen Tasks eines Workspace.
Ein Schedule benennt Task, Cron-Ausdruck und den Workspace, unter dem er läuft. Der Worker löst den Kontext zur Laufzeit auf — ein pausierter oder gelöschter Schedule produziert ohne Redeploy keine Arbeit mehr.
listWorkspaceSchedules()
upsertScheduleAction({ task, cron })
removeScheduleAction(formData)Implementierungsablauf
Behandle jeden geplanten Lauf als unvertrauenswürdige Eingabe: Löse Workspace und Entitlement im Lauf neu auf, weil sich der Zustand seit der Registrierung geändert haben kann. Mache den Task idempotent — ein wiederholter oder doppelt gefeuerte Lauf darf keine Effekte duplizieren.
Schedules sind operative Fläche: Halte sie in Settings oder Logs sichtbar, damit ein hängender oder außer Kontrolle geratener Schedule gefunden wird, bevor Nutzer es merken.
Überprüfung und Fehlerbehebung
Feuere den Schedule manuell in einer Sandbox, pausiere ihn, verifiziere, dass ein deaktivierter Workspace keine Läufe mehr produziert, und bestätige, dass ein doppelt gefeuerte Lauf nur einen Effekt erzeugt. Halte Cron-Ausdrücke in verwalteter Konfiguration, nicht verstreut im Task-Code.