suche
ESC

Automatisierung

Cron, Skripte und Workflow-Automation für wiederkehrende Aufgaben einsetzen.

Second-Level Automation 30 Min +180 XP

Worum geht’s

Was du manuell zum dritten Mal machst, automatisierst du. Backups, Cleanups, Health-Reports — im Second-Level kapselst du wiederkehrende Aufgaben in Skripte und planst sie per Cron oder über Workflow-Tools. Wer Cron-Ausdrücke sicher liest und schreibt, baut zuverlässige Zeitsteuerung, die nicht zur falschen Stunde losläuft.

Konzept

  • Cron-Syntax (5 Felder): Minute Stunde Tag-des-Monats Monat Wochentag. * = jeder Wert, */15 = alle 15, 1-5 = Bereich, 0,30 = Liste. 0 9 * * 1-5 = werktags 09:00. */15 * * * * = alle 15 Minuten.
  • Häufige Fehler: Felder verwechselt (Minute vs. Stunde), * statt eines festen Werts (läuft viel zu oft), Zeitzone des Cron-Daemons nicht bedacht.
  • Skripte robust machen: definierte PATH/Umgebung (Cron erbt nicht deine Login-Shell), set -euo pipefail in Bash (Fehler stoppen das Skript), Idempotenz (zweimal laufen lassen darf nicht schaden), Logging und ein Exit-Code, an dem das Monitoring den Erfolg erkennt.
  • Cron vs. Workflow-Automation: Cron ist ideal für simple Zeit-Trigger auf einem Host. Sobald Ereignisse, mehrere Systeme, Bedingungen und Fehler-Retries ins Spiel kommen, lohnt ein Workflow-Tool wie n8n — Trigger (Webhook, Zeitplan), verkettete Schritte, Fehlerpfade, sichtbarer Lauf-Status.

Konzept-Visualizer

Tippe einen Cron-Ausdruck oder wähle ein Preset und sieh die nächsten Ausführungszeiten. Ändere ein Feld und beobachte, wie sich der Rhythmus verschiebt.

    Beispiel-Fall

    Gegeben: Ein Backup-Skript soll jeden Werktag um 03:30 nachts laufen. Welcher Cron-Ausdruck, und worauf achten?

    1. Felder zuordnen: Minute 30, Stunde 3, Tag *, Monat *, Wochentag 1-5 (Mo–Fr) → 30 3 * * 1-5.
    2. Gegenprobe: läuft es wirklich nur werktags? 1-5 schließt Sa(6)/So(0) aus — passt.
    3. Zeitzone prüfen: läuft der Cron-Daemon in UTC, ist 03:30 UTC ggf. 04:30/05:30 Ortszeit. Für ein nächtliches Fenster relevant.
    4. Skript robust: set -euo pipefail, Backup in eine Logdatei, am Ende Exit-Code 0 nur bei Erfolg — sonst meldet das Monitoring den Fehlversuch.
    5. Verifizieren: Eintrag testweise auf „in 2 Minuten” stellen, einmal laufen lassen, Log und Exit-Code prüfen, dann auf 30 3 * * 1-5 zurücksetzen.

    Lehre: Felder zuordnen → Wochentage gegenprüfen → Zeitzone bedenken → Skript fehlerfest → einmal echt testen.

    Anwenden

    ▶ Am Tool ausprobieren

    Verlass dich nicht auf das Gefühl — lass dir den Ausdruck bauen und die nächsten Ausführungen anzeigen, bevor er produktiv läuft.

    1. Baue den Ausdruck für „werktags 03:30 nachts“ zusammen.
    2. Vergleiche die Vorschau der nächsten Läufe mit deiner Erwartung.
    3. Ändere den Wochentag auf nur Montag (1) und prüfe, wie sich die Termine ändern.
    Tool öffnen: /cron-builder ↗

    Für mehrstufige, ereignisgetriebene Abläufe lohnt der Blick auf Workflow-Automation: die Beiträge „Automatisierung mit n8n” und „n8n + Ollama” zeigen, wann ein Workflow-Tool die bessere Wahl als ein nackter Cronjob ist.

    Selbsttest

    Praxis-Challenge

    ⚑ Praxis-Challenge

    Plane ein wöchentliches Cleanup, das sonntags um 02:00 laufen soll. Baue den Ausdruck im Cron-Builder, prüfe die nächsten Läufe und beschreibe drei Robustheits-Maßnahmen für das zugehörige Skript (z. B. Fehlerabbruch, Logging, Idempotenz). Begründe, ob Cron hier reicht oder ein Workflow-Tool besser wäre.

    Tool öffnen: /cron-builder ↗

    Modul im Speedrun testen →