> ## Documentation index
> The full klickops handbook index is at https://klickops.io/llms.txt
> The HTML of this page is at https://klickops.io/docs/scheduled-jobs
> Language: de

# Scheduled Jobs

Ein Container, der nach Zeitplan läuft, seine Arbeit macht und sich beendet.

## Was das ist

Ein Scheduled Job ist ein Container, den klickops nach Fahrplan startet. Er läuft, wird fertig und verschwindet bis zum nächsten Mal. Jeder Start ist ein Run, mit eigenem Exit-Code und eigenen Logs, so lange aufbewahrt, wie du willst.

Das ist das Gegenstück zur App. Eine App soll laufen und wird neu gestartet, wenn sie sich beendet. Ein Job soll sich beenden, und Weiterlaufen ist der Fehlerfall.

## Wann du das brauchst

- Ein nächtlicher Export, ein Rechnungslauf, ein Aufräumjob.
- Ein wiederkehrender Abruf bei einer fremden API.
- Eine Migration, die du auf einem Timer laufen lassen willst statt von Hand.

> [!Nicht dafür]
> Arbeit, die auf ein Ereignis reagiert statt auf eine Uhrzeit, ist kein Scheduled Job. Ein Queue-Consumer, der immer zuhören muss, ist eine App.

## Einen anlegen

1. Öffne das Projekt, geh auf **Scheduled jobs** und dann auf **New scheduled job**.
2. Gib ihm einen Namen und das Image, das laufen soll. Ein Kommando ist optional. Ohne eines läuft der Entrypoint des Images.
3. Setz den Zeitplan. Er ist ein Cron-Ausdruck, und der Standard `0 * * * *` bedeutet zu jeder vollen Stunde. Die Seite zeigt die nächsten Läufe im Klartext, damit du prüfen kannst, ob der Ausdruck meint, was du denkst.
4. Lass die Ressourcen auf automatisch, ausser du weisst, dass der Job schwer ist.
5. Leg ihn an. Er erscheint mit seiner nächsten Laufzeit und wartet.

![Die Liste der Scheduled Jobs, mit den nächsten 24 Stunden und dem letzten Ergebnis pro Job.](/handbook/scheduled-jobs-list.webp)

## Beobachten

Öffne den Job. Der Tab **Runs** listet jeden Start mit Ergebnis und Dauer. Jeder Run behält seine eigenen Logs, und das ist der Unterschied zwischen "hat nicht geklappt" und zu wissen, warum.

Du kannst jederzeit einen Run von Hand starten. Der läuft sofort, ohne den Zeitplan anzufassen. So testest du die Sache, bevor du sie einem Timer anvertraust.

## Einstellungen im Überblick

| Einstellung | Standard | Was sie bewirkt |
| --- | --- | --- |
| Zeitplan | `0 * * * *` | Cron-Ausdruck. Standardmässig stündlich. |
| Zeitzone | die des Clusters | Nach welcher Uhr der Zeitplan geht. Setz sie, wenn dein Job lokale Mitternacht meint. |
| Concurrency | Allow | Was passiert, wenn ein Run noch läuft und der nächste ansteht. `Forbid` lässt ihn aus, `Replace` beendet den alten. |
| Aufbewahrte Runs | 3 erfolgreiche, 1 fehlgeschlagener | Wie viel Verlauf und wie viele Logs bleiben. |
| Ressourcen | automatisch | CPU und Memory. Zieh sie hoch für einen Job, der echte Arbeit macht. |
| Pausiert | nein | Hält den Zeitplan an, ohne den Job zu löschen. |

## Grenzen und Fallstricke

- **`Allow` ist der Standard und bedeutet Überlappung.** Ein Job, der länger dauert als sein Intervall, läuft doppelt. Ist das unsicher, setz `Forbid`.
- **Ein verpasstes Fenster wird nicht nachgeholt.** Konnte der Cluster einen Run nicht starten, ist dieser Termin weg und steht nicht in einer Warteschlange.
- **Logs verschwinden mit ihrem Run.** Die Aufbewahrung bestimmt, wie weit du zurückschauen kannst, und standardmässig bleiben nur die letzten drei Erfolge.
- **Ein Job, der sich nie beendet, blockiert den nächsten** unter `Forbid` und stapelt sich unter `Allow`. Gib langen Jobs ein eigenes Timeout.

## Verwandt

- [Apps](/docs/apps) für Arbeit, die durchgehend laufen muss.
- [Secrets](/docs/secrets), falls der Job Zugangsdaten braucht.