Scheduler

Der Scheduler startet Migrationen wiederkehrend, ohne Bedienung der Oberfläche. Die Planung ist je Migration einstellbar; einen globalen Zeitplan gibt es nicht.

Intervall einstellen

In der Migration unter „Automatische Synchronisierung“:

Auswahl	Wert
Deaktiviert	kein Zeitplan
Alle 5 Minuten	5
Alle 15 Minuten	15
Alle 30 Minuten	30
Stündlich	60
Täglich	1440

Über die API ist jeder Wert von 1 bis 43200 Minuten zulässig (bis 30 Tage). Deaktiviert entspricht auto_sync_interval_minutes = null.

curl -X PATCH http://127.0.0.1:8000/api/v1/jobs/<job-id> \
  -H "Content-Type: application/json" \
  -H "X-CSRF-Token: <csrf-token>" \
  -b cookies.txt \
  -d '{"auto_sync_interval_minutes": 60}'

Zeitplan deaktivieren:

curl -X PATCH http://127.0.0.1:8000/api/v1/jobs/<job-id> \
  -H "Content-Type: application/json" \
  -H "X-CSRF-Token: <csrf-token>" \
  -b cookies.txt \
  -d '{"auto_sync_interval_minutes": null}'

Zeitbasis und Zeitzone

Gespeichert wird next_run_at in UTC.
Die Oberfläche zeigt Termine in der lokalen Zeitzone des Browsers.
Ein Intervall ist eine feste Dauer ab Einreihung, kein Kalenderzeitpunkt. Bei „Täglich“ verschiebt sich der Termin entsprechend der Laufzeit des vorherigen Laufs.

Ablauf eines geplanten Laufs

Die Warteschlange prüft im Poll-Intervall (QUEUE_POLL_SECONDS, Standard 2 s), ob ein Termin fällig ist.
Ist die Migration aktiviert und nicht beschäftigt, wird ein Lauf mit trigger = schedule eingereiht.
next_run_at wird auf jetzt + Intervall gesetzt.
Der Lauf wird nach Priorität und Erstellzeitpunkt abgearbeitet, sobald ein Platz frei ist.

Der Zeitplan erzeugt nur Läufe; er ändert weder Ordnerauswahl noch Ziel.

Beschäftigte Migration

Läuft für dieselbe Migration bereits ein Lauf, wird kein zweiter eingereiht. Der Termin bleibt fällig und wird nach Abschluss einmal nachgeholt. Dadurch entsteht kein Stapel aufgelaufener Läufe.

Verpasste Termine

War die Anwendung zum geplanten Zeitpunkt nicht in Betrieb, bleibt next_run_at in der Vergangenheit. Beim nächsten Start wird der Termin als fällig erkannt und einmal eingereiht; danach gilt wieder das normale Intervall.

Es werden also nicht alle verpassten Termine nachgeholt, sondern genau einer. Das verhindert eine Lastspitze nach längerer Downtime.

Zusammenspiel mit Wiederholungen

Zeitplan und Wiederholung sind getrennte Mechanismen:

Der Scheduler erzeugt Läufe nach Intervall (trigger = schedule).
Die Wiederholung erzeugt Läufe nach einem Fehler (trigger = retry), mit exponentiellem Backoff und begrenzter Anzahl.

Beide können auf dieselbe Migration wirken. Ist sie beschäftigt, werden fällige Termine und fällige Wiederholungen zurückgestellt, bis der laufende Lauf beendet ist.

Pausieren der Warteschlange

Ist die Warteschlange pausiert, werden keine neuen Läufe eingereiht — auch keine geplanten. Die Termine bleiben fällig und werden nach dem Fortsetzen nachgeholt. Laufende Prozesse werden durch das Pausieren nicht beendet.

Deaktivierte Migrationen

Eine deaktivierte Migration (enabled = false) wird vom Scheduler übersprungen, auch wenn ein Intervall gesetzt ist. Beim Wiederaktivieren bleibt der alte Termin bestehen; ist er abgelaufen, wird er beim nächsten Durchlauf einmal eingereiht.

Übersicht prüfen

curl http://127.0.0.1:8000/api/v1/queue -b cookies.txt

Relevante Felder: next_scheduled, scheduler_enabled, paused, max_concurrency, active_count, queued_count.

Grenzen

Die Auflösung beträgt ein Poll-Intervall; ein Lauf startet nicht sekundengenau.
Keine Cron-Ausdrücke, keine Wochentage, keine Zeitfenster — nur feste Intervalle.
Die Planung gilt immer für die gesamte Migration, nicht für einzelne Ordner.
Bei sehr kurzen Intervallen und langen Laufzeiten laufen Termine ineinander; die Migration bleibt dauerhaft beschäftigt und holt Termine nur einmal nach. Für große Postfächer sind längere Intervalle sinnvoll.
Die Zeitplanung wurde mit automatisierten Tests geprüft, nicht in einem echten Microsoft-365-Dauerbetrieb.