(Cron-Jobs · Nautilus)
An die Grenze des Schedulers Ihrer Plattform gestoßen? Nautilus ruft jede öffentliche URL nach einem von Ihnen festgelegten Cron-Zeitplan auf, bis zu einmal pro Minute. Ein fehlgeschlagener Aufruf wird wiederholt, jeder Versuch wird protokolliert, und Zeitpläne werden per API statt in einer Konfigurationsdatei gesetzt. Zeitpläne laufen in UTC.
curl -X POST https://api.vernesoft.com/v1/clockwork/jobs \
-H "Authorization: Bearer vrn_clockwork_•••" \
-d '{"name":"billing","schedule":"0 0 1 * *","url":"https://api.yourdomain.com/billing"}'(Wo Cron aufhört)
Ein Crontab ist auf einer Maschine in Ordnung, und der Scheduler einer Plattform ist innerhalb dieser Plattform in Ordnung. Ärger beginnt am Rand: der kostenlose Tarif, der einen Lauf pro Tag erlaubt, der zweite Server, der denselben Job zweimal auslöst, der Fehler, den niemand gesehen hat.
Crontab und Plattform-Scheduler
Cron-Jobs in Nautilus
(Kernfunktionen)
(01)
Der Zeitplan lebt bei uns, nicht in jeder Instanz Ihrer App, sodass Skalierung ihn nicht vervielfachen kann. Auf unserer Seite wird jeder fällige Lauf in der Datenbank reserviert, bevor er startet, sodass ein zweiter Worker, der denselben Job sieht, ihn bereits vergeben findet.
(02)
Legen Sie Zeitpläne per API an, pausieren, ändern und löschen Sie sie, oder planen Sie eine einmalige Aufgabe für einen bestimmten Zeitpunkt. Wenn Ihre Kunden in Ihrem Produkt eigene wiederkehrende Aufgaben definieren, legt Ihr Backend den Job an, sobald sie speichern.
(03)
Ein fehlgeschlagener Lauf bekommt bis zu drei Versuche: den ersten, dann Wiederholungen eine Minute und fünf Minuten später. Der Wiederholungszustand lebt beim Job statt im Speicher, sodass eine ausstehende Wiederholung einen Worker-Neustart oder ein Deployment übersteht.
(04)
Der Scheduler wacht einmal pro Minute auf und startet, was fällig ist, sodass ein Job für 09:00 bei der ersten Prüfung um oder nach 09:00 startet, nicht irgendwo innerhalb der Stunde. Es gibt kein Sekundenfeld, und jeder Zeitplan läuft in UTC.
(05)
Jeder Versuch wird mit Startzeit, Dauer, dem HTTP-Status Ihres Endpoints und dem Antwort-Body gespeichert, oder mit dem Fehler, wenn der Aufruf nie zustande kam. Der Verlauf wird für das Zeitfenster Ihres Tarifs aufbewahrt, das auf der Preisseite steht.
(06)
Standard-Cron-Ausdrücke mit fünf Feldern, aufgelöst in UTC: Es gibt keine Zeitzonen und keine Kurzmakros wie daily oder hourly. Ein Zeitplan, der Tag des Monats und Wochentag zugleich einschränkt, wird abgelehnt statt erraten, ebenso einer, der nie auslösen kann.
(Teil von Nautilus)
Cron-Jobs sind ein Teil von Nautilus, im selben Konto und Dashboard wie Anmeldung und Webhook-Zustellung. Der Scheduler ist unser eigener Code. Anmeldung und Webhook-Zustellung laufen auf Open-Source-Engines, die Sie selbst hosten könnten; dieser Teil geht nicht mit Ihnen, wenn Sie gehen. Was mitgeht: Jeder Job und jeder Lauf ist über die API lesbar.
(Entwicklererfahrung)
Geben Sie einen Cron-Ausdruck und eine URL an, über ein offizielles SDK oder eine einfache HTTP-Anfrage. Eine einmalige Aufgabe nimmt stattdessen einen UTC-Zeitstempel.
curl -X POST https://api.vernesoft.com/v1/clockwork/jobs \
-H "Authorization: Bearer $VERNE_CLOCKWORK_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Monthly Billing Run",
"schedule": "0 0 1 * *",
"url": "https://api.yourdomain.com/billing/process",
"method": "POST",
"body": "{\"batch\":\"auto\"}"
}'(FAQ)
Der Zeitplan lebt bei uns, zusätzliche Instanzen Ihrer App ändern also nichts. Auf unserer Seite wird jeder fällige Lauf per bedingtem Update in der Datenbank reserviert, bevor etwas startet: Ein zweiter Worker, der denselben Job sieht, findet die Zeile bereits vorgerückt und tut nichts. Das ergibt einen Auslöser pro geplantem Zeitpunkt. Die Zustellung selbst ist at-least-once, weil ein fehlgeschlagener Versuch wiederholt wird; machen Sie Ihren Endpoint daher idempotent und nutzen Sie den Header X-Clockwork-Attempt, um Seiteneffekte abzusichern.
Jeder Lauf bekommt bis zu drei Versuche: den ersten, dann Wiederholungen eine Minute und fünf Minuten später. Netzwerkfehler, 5xx und 429 werden wiederholt; andere 4xx-Antworten nicht, da eine identische Wiederholung dieselbe Antwort bekäme. Jeder Versuch wartet bis zu 30 Sekunden auf eine Antwort, und Weiterleitungen werden nicht verfolgt, geben Sie also die endgültige URL an. Jeder Versuch wird mit der erhaltenen Antwort gespeichert, und eine ausstehende Wiederholung übersteht einen Worker-Neustart.
Ja. Neben wiederkehrenden Ausdrücken können Sie eine einmalige Aufgabe für einen UTC-Zeitstempel planen, zum Beispiel das Senden einer E-Mail 24 Stunden nach der Registrierung. Sie wird bei der Einmal-pro-Minute-Prüfung des Schedulers aufgegriffen, wie alles hier.
Ja. Ein Job ist ein HTTP-Aufruf an eine öffentliche URL, er kann also auf eine Route Ihres Vercel-Deployments zeigen, mit den Headern, die er braucht, um Ihre eigenen Prüfungen zu passieren, bis zu einmal pro Minute. Die Funktion läuft weiterhin auf Vercel, es gelten also Vercels eigene Dauer- und Nutzungslimits; Nautilus übernimmt nur den Aufruf, und diese Läufe zählen nicht auf Ihr Anfragenkontingent. Zur Einordnung: Vercels Dokumentation (geprüft am 3. Oktober 2026) enthält Cron in jedem Tarif, auch Hobby, begrenzt Hobby aber auf einen Lauf pro Tag mit Zeitgenauigkeit nur auf die Stunde; Pro läuft minütlich. Die anderen hören an ihren eigenen Grenzen auf: pg_cron erreicht nur, was Ihre Datenbank erreichen kann, und ein GitHub-Actions-Zeitplan kann laut eigener Dokumentation bei hoher Last verspätet starten.
Legen Sie mit POST /v1/clockwork/delayed einen Delayed Job eine Minute in der Zukunft an und beobachten Sie ihn im Ausführungslog. Einen Jetzt-ausführen-Button gibt es noch nicht. Ein einmaliger Lauf nutzt denselben Worker und dieselben Logs wie ein wiederkehrender.
Ja, ohne Karte. Clockwork verbraucht Ihr Anfragenkontingent nicht: Geplante Läufe und Aufrufe der Clockwork-API werden darauf nicht angerechnet. Was jeder Tarif begrenzt, ist die Zahl der gleichzeitig aktiven Jobs: Der kostenlose Tarif erlaubt 10 wiederkehrende Jobs und 100 wartende Delayed Jobs, Starter 100 und 1.000, Pro 1.000 und 10.000. Starter kostet 19 € und Pro 79 € im Monat; die aktuelle Liste steht auf der Preisseite.
Heute nicht. Nichts sendet einen Alarm, wenn ein Lauf fehlschlägt. Jeder Versuch wird mit dem erhaltenen Status und Body protokolliert, und Sie können das Log im Dashboard lesen oder den Executions-Endpoint abfragen, sodass eine eigene Prüfung den Alarm auslösen kann.
(Loslegen)
Cron-Jobs sind ein Teil von Nautilus: dasselbe Konto und dasselbe Dashboard wie Anmeldung und Webhook-Zustellung.
Wann Sie das nicht brauchen
Wenn Sie eine Anwendung auf einer Maschine betreiben, ist crontab völlig in Ordnung und sollte bleiben. Dasselbe gilt für Arbeit, die ihre Plattform nie verlässt: Vercel Cron passt zu einer Vercel-Funktion, pg_cron passt zu einem Job, der nur Ihre Supabase-Datenbank berührt, und ein GitHub-Actions-Zeitplan reicht für eine nächtliche Aufgabe, die auch später laufen darf.
Nautilus verdient sich seinen Platz an der Grenze, an der diese aufhören, und diese Grenze kommt früher, als man denkt. Die zweite Instanz, bei der zwei Kopien desselben Crontabs denselben Abrechnungslauf zweimal auslösen. Der Job, der einen Dienst auf einem anderen Host aufrufen muss. Der Zeitplan, den Ihre eigenen Kunden in Ihrem Dashboard setzen. Der kostenlose Tarif, der einen täglichen Job irgendwo innerhalb der Stunde startet. Der Lauf, der um 03:00 fehlschlug und keine Spur hinterließ.
Diese fünf Fälle beantwortet Nautilus: eine Ausführung pro Zeitplan, egal wie viele Instanzen Sie ausrollen, jede öffentliche URL auf jedem Host, per API angelegte und abgebrochene Zeitpläne, minutengenaues Timing in jedem Tarif und ein Log jedes Versuchs mit der erhaltenen Antwort. Geplante Läufe zählen nicht auf Ihr Anfragenkontingent, und der kostenlose Tarif erlaubt 10 aktive wiederkehrende Jobs.