Cron Job Helper — Manual

Zurück zur Übersicht: Cron Job Helper · Tool live öffnen: www.jpkc.com/tools/cron/

Dieses Manual beschreibt den Cron Job Helper vollständig: die Cron-Syntax, die das Tool versteht, jeden der fünf Reiter und die Befehle, die dabei entstehen. Die Oberfläche ist auf Englisch — die Tab- und Feld-Bezeichnungen werden hier in ihrer englischen Original-Schreibweise genannt (mit deutscher Erläuterung), damit du dich im Interface wiederfindest.

Die Cron-Syntax: fünf Felder

Ein klassischer Cron-Ausdruck besteht aus fünf durch Leerzeichen getrennten Feldern, gefolgt vom auszuführenden Befehl. Das Tool prüft und berechnet Ausdrücke so, wie Vixie cron und dessen Nachfolger cronie sie lesen — also der Cron, der auf den gängigen Linux-Distributionen läuft. Im Reference-Tab steht der Aufbau als Diagramm:

┌─────────── minute (0–59)
│ ┌───────── hour (0–23)
│ │ ┌─────── day of month (1–31)
│ │ │ ┌───── month (1–12)
│ │ │ │ ┌─── day of week (0–7, 0/7 = Sun)
│ │ │ │ │
* * * * *  command to execute

Die erlaubten Werte und Sonderzeichen pro Feld:

Beim Wochentag sind 0 und 7 beide Sonntag. Monate und Wochentage darfst du auch als Drei-Buchstaben-Namen schreiben, unabhängig von Groß- und Kleinschreibung — einzeln, als Bereich oder in Listen (mon-fri, jan,jul, sun).

Die Sonderzeichen

Die Zeichen lassen sich kombinieren: Ein Listeneintrag darf selbst ein Bereich oder ein Schritt sein (0-10/5,30,45). Ein Schritt muss mindestens 1 sein; ein Bereich muss aufsteigend notiert werden (1-5, nicht 5-1). Die Kurzform 5/15 (Startwert mit Schritt, aber ohne Bereich) liest das Tool wie cronie als 5-59/15 und warnt, weil manche Cron-Versionen sie ablehnen — sicherer ist die ausgeschriebene Form.

Schritte beginnen in jeder Stunde bzw. an jedem Tag neu beim Feld-Minimum: */7 im Minutenfeld heißt Minute 0, 7, … 56 und danach wieder 0 — über die Stundengrenze liegen nur vier Minuten. Teilt der Schritt 60 (Minute) bzw. 24 (Stunde) nicht glatt, blendet das Tool genau diesen Hinweis ein.

Tag des Monats und Wochentag: die ODER-Regel

Sind beide Tagesfelder eingeschränkt, läuft der Job an jedem Tag, an dem eines der beiden passt: 0 0 1 * 1 läuft am 1. jedes Monats und an jedem Montag. Als „uneingeschränkt“ zählt dabei jedes Feld, das mit * beginnt — also auch */2. Ist nur eines der beiden Felder eingeschränkt, müssen beide passen. Das Tool rechnet die nächsten Läufe nach genau dieser Regel und formuliert sie im Klartext ausdrücklich: „on day 1 of the month OR on Monday (either one matches)“.

Was das Tool ablehnt: Quartz- und Spring-Syntax

Die Zeichen ?, L, W und # sowie ein Sekundenfeld stammen aus Quartz, Spring und anderen Schedulern. Der Linux-Cron kennt sie nicht. Die vier Zeichen behandelt das Tool als Fehler — etwa 0 0 L * * mit der Meldung „? L W # are Quartz/Spring syntax — standard cron does not know them.“ Für „letzter Tag des Monats“ zeigt der Reference-Tab die Cron-taugliche Umschreibung mit einem Datumstest:

0 0 28-31 * * [ "$(date -d tomorrow +\%d)" = 01 ] && command

Folgt auf fünf Zeitfelder ein sechstes, das wie ein Zeitfeld aussieht, warnt das Tool: Standard-Cron hat weder Sekunden noch Jahr, das sechste Feld wäre bereits der Befehl.

Spezialstrings

Statt fünf Felder akzeptiert Cron auch @-Kürzel. Das Tool kennt sie im Manual Input und löst sie auf:

@reboot hat keinen kalkulierbaren Zeitplan — die Next Scheduled Runs zeigen dafür keine Vorschau, sondern den Hinweis, dass der Job nur beim Start des Cron-Daemons läuft (in der Regel beim Booten). Auch hinter einem Spezialstring darf ein Befehl folgen (@daily /usr/bin/backup.sh). Ein unbekannter @-String wird als Fehler gemeldet.

Reiter 1 — Builder

Der Builder ist das Herzstück. Oben steht die Karte Cron Expression: der aktuelle Ausdruck (Standard * * * * *), mit dem Feldnamen unter jedem Teil (minute, hour, day, month, weekday bzw. shortcut bei einem @-String). Darunter folgen eine Klartext-Beschreibung (etwa „At 03:00“ oder „Every 15 minutes“), bei einer eingefügten Crontab-Zeile die Zeile Command: mit dem erkannten Befehl und gegebenenfalls gelb hervorgehobene Warnungen. Ein fehlerhaftes Feld ist im Ausdruck markiert, die Beschreibung lautet dann „Invalid expression“.

Der Copy-Button kopiert den Ausdruck — samt Befehl, falls einer erkannt wurde — in die Zwischenablage. Bei einem ungültigen Ausdruck kopiert er nichts und meldet „The expression is not valid yet.“

Die Feld-Karten

Darunter liegt für jedes der fünf Felder eine Karte (Minute, Hour, Day of Month, Month, Day of Week), im Kopf mit dem erlaubten Wertebereich (beim Wochentag „0–7, Sun = 0 or 7“) und einem Auswahlmenü für den Modus:

• Every <Feld> — jeder Wert (*).
• Every N <Feld>s (*/N) — Schritt: ein Zahlenfeld Every erscheint, daraus wird */N.
• Specific value — ein fester Einzelwert; ein Zahlenfeld Value im erlaubten Bereich des Feldes.
• Range (A–B) — ein Bereich; zwei Felder From/to erzeugen A-B.
• List / custom — ein freies Textfeld Values für Listen wie 0,15,30,45 und für jede andere gültige Syntax: Namen (mon-fri), Bereiche mit Schritt (9-17/2) oder Kombinationen.

Jede Änderung aktualisiert sofort den Ausdruck oben, die Klartext-Beschreibung und die Liste der nächsten Läufe. Ist ein Feld ungültig, bekommt seine Karte einen roten Rahmen.

Manual Input

Wer den Ausdruck lieber direkt eintippt, nutzt das Feld Manual Input (mit dem Präfix $ cron). Es akzeptiert fünf leerzeichengetrennte Felder (z. B. */5 * * * *) oder einen Spezialstring (@daily). Alles, was nach den fünf Feldern bzw. dem Spezialstring folgt, gilt als Befehl — du kannst also eine komplette Zeile aus deiner Crontab einfügen und prüfen. Der Befehl erscheint in der Cron Expression-Karte, bleibt erhalten, wenn du danach die Feld-Karten änderst, und wird beim Kopieren mitgenommen. Ein Klick auf einen Preset ersetzt dagegen die ganze Eingabe.

Ist die Eingabe ungültig, listet das Tool unter dem Feld jede Fehlermeldung einzeln auf. Eine gültige Eingabe synchronisiert die Feld-Karten zurück, sodass Builder und Texteingabe immer denselben Stand zeigen; Einträge, die keinem der einfachen Modi entsprechen, landen dabei im Modus List / custom.

Fehler und Warnungen

Das Tool unterscheidet zwei Stufen. Fehler machen den Ausdruck ungültig — es gibt dann weder Klartext noch Vorschau:

• weniger als fünf Felder oder eine leere Eingabe,
• ein Wert außerhalb des Feldbereichs (61 als Minute) oder ein unbekannter Name,
• ein Schritt von 0 oder ein nicht numerischer Schritt (*/0),
• ein rückwärts notierter Bereich (5-1) oder ein leerer Listeneintrag (1,,2),
• Quartz-/Spring-Zeichen (? L W #) und ein unbekannter @-String.

Warnungen lassen den Ausdruck gültig, weisen aber auf eine Falle hin:

• a/n ohne Bereich (z. B. 5/15) — wird als 5-59/15 gelesen, manche Cron-Versionen lehnen die Kurzform ab,
• ein sechstes Feld, das nach Sekunden oder Jahr aussieht — Standard-Cron liest es als Befehl,
• ein Schritt, der die Stunde bzw. den Tag nicht glatt teilt (*/7, */5 im Stundenfeld) — mit der tatsächlichen Lücke an der Grenze.

Quick Presets

Rechts liegen 16 Quick Presets als Buttons, die einen Ausdruck per Klick setzen:

Every minute (* * * * *), Every 5 min (*/5 * * * *), Every 15 min (*/15 * * * *), Every 30 min (*/30 * * * *), Every hour (0 * * * *), Every 2 hours (0 */2 * * *), Every 6 hours (0 */6 * * *), Every 12 hours (0 */12 * * *), Daily midnight (0 0 * * *), Daily 3 AM (0 3 * * *), Weekly (Sun) (0 0 * * 0), Weekly (Mon) (0 0 * * 1), Monthly 1st (0 0 1 * *), Yearly Jan 1st (0 0 1 1 *), Weekdays 9 AM (0 9 * * 1-5) und Weekends (0 0 * * 6,0).

Next Scheduled Runs

Ebenfalls rechts berechnet das Tool die nächsten acht Ausführungszeitpunkte aus dem aktuellen Ausdruck. Darüber wählst du unter Time zone of the server die Zeitzone, in der dein Cron tatsächlich läuft: Voreingestellt ist This browser (…) mit der Zeitzone deines Browsers, darunter folgen UTC und unter All time zones jede Zeitzone, die dein Browser kennt. Die Auswahl merkt sich das Tool im localStorage. Ein Hinweistext erinnert daran, dass Cron die Zeitzone der Maschine nutzt, auf der er läuft — auf Servern und in Containern oft UTC; prüfen kannst du sie mit date +%Z oder timedatectl, und cronie liest zusätzlich CRON_TZ=Europe/Berlin am Anfang einer Crontab.

Jeder Lauf erscheint mit Wochentag, Datum und Uhrzeit im Format Wed 2026-10-21 03:00, dem Kürzel der Zeitzone (z. B. CEST) und einer relativen Angabe (now, in 5 min, in 2h 5m, in 3d 4h, ab 60 Tagen in Monaten, ab zwei Jahren in Jahren). Die Liste aktualisiert sich jede Minute von selbst. Die Berechnung schaut bis zu 28 Jahre in die Zukunft — danach wiederholt sich der Kalender —, sodass auch seltene Termine wie der 29. Februar gefunden werden. Gibt es auch in diesem Fenster keinen Treffer, existiert das Datum nie (etwa der 30. Februar oder der 31. in einem Monat mit 30 Tagen), und das Tool sagt das.

Sommerzeit berechnet das Tool so, wie cronie sie behandelt:

• Ein Job mit fester Uhrzeit (Minute und Stunde beginnen nicht mit *), dessen Zeit in der übersprungenen Stunde liegt, läuft direkt nach der Umstellung — der Lauf trägt den Hinweis „DST: 02:30 does not exist — cronie runs it right after the jump“. In der doppelten Stunde im Herbst läuft er nur einmal („fixed-time job runs once“).
• Ein Wildcard-Job (etwa */30 2 * * *) folgt der Wanduhr: In der übersprungenen Stunde läuft nichts, die doppelte Stunde durchläuft er zweimal („DST: hour repeated — runs again“).

Mehr dazu in den Tipps zur Zeitzonen-Frage.

Reiter 2 — Web Cron

Der Web Cron-Tab erzeugt einen Cron-Job, der per HTTP eine URL aufruft, statt ein lokales Skript zu starten — praktisch für Shared Hosting oder CMS-Aufgaben. Der Zeitplan läuft dabei weiterhin im System-Cron, nur der Befehl ist ein HTTP-Request. Du konfigurierst links, rechts entstehen live zwei Ausgaben: die Generated Crontab Line (komplette Zeile mit Zeitplan) und Command only (nur der Befehl), beide mit eigenem Copy-Button. Solange keine URL eingetragen ist, steht dort nur ein Platzhalter.

Die Konfigurationsfelder:

• Tool — curl (recommended) oder wget.
• URL to call — die aufzurufende Adresse.
• Cron schedule — der Zeitplan (Standard */15 * * * *). Der Button Builder daneben übernimmt den aktuellen Ausdruck aus dem Builder-Tab. Das Tool prüft den Zeitplan mit demselben Parser wie der Builder und zeigt darunter die Klartext-Beschreibung oder die Fehlermeldung. Achtung: Ist das Feld leer oder der Zeitplan ungültig, erzeugt das Tool die Generated Crontab Line trotzdem — dann ersatzweise mit */15 * * * *. Prüf vor dem Kopieren also, ob unter dem Feld eine Fehlermeldung steht. Hier gehört nur der Zeitplan hin — tippst du einen Befehl dahinter, meldet das Feld „Only the schedule here — the command is generated below.“
• Timeout (sec) — Standard 30. Das Eingabefeld schlägt 5–300 Sekunden vor, der Generator übernimmt aber jeden Wert von 1 bis 3600 Sekunden (größere Werte kappt er auf 3600); 0, ein leeres Feld oder eine ungültige Eingabe ergeben den Standard 30. Wird zu --max-time (curl) bzw. --timeout= (wget).
• HTTP Method — GET oder POST (curl: -X POST, wget: --post-data='').
• Log file path (optional) — hängt >> 'datei' 2>&1 an.
• User-Agent (optional) — -A (curl) bzw. --user-agent= (wget).
• HTTP Auth User / Pass (optional) — -u 'user:pass' (curl) bzw. --user=/--password= (wget).
• Read credentials from ~/.netrc instead of the command line — statt der Zugangsdaten setzt curl --netrc; wget liest die Datei ohnehin selbst und bekommt keine Auth-Optionen. Die Option wirkt nur zusammen mit einem eingetragenen HTTP Auth User: Setzt du nur den Haken und lässt den Benutzer leer, kommt bei curl kein --netrc in die Zeile, und das Tool zeigt auch keine .netrc-Vorlage. Das Passwort-Feld darf dagegen leer bleiben — dann steht in der Vorlage der Platzhalter YOUR_PASSWORD.
• Silent mode (suppress output) (Standard aktiv) — curl bekommt -sS (Fortschrittsanzeige aus, echte Fehler weiterhin sichtbar), wget -q. Ist Silent aus, gibt curl per -w '%{http_code}\n' den HTTP-Status aus.
• Skip SSL verification — -k (curl) bzw. --no-check-certificate (wget); nur für Testzwecke.

Unabhängig von den Optionen setzt das Tool bei curl immer --fail (Exit-Code ungleich 0 bei HTTP 4xx/5xx) und verwirft die Antwort mit -o /dev/null; wget bekommt --tries=1 und -O /dev/null. Ohne Logdatei wird bei aktivem Silent mode zusätzlich > /dev/null 2>&1 angehängt.

Quoting: Alle Werte (URL, User-Agent, Zugangsdaten, Logdatei) stehen in einfachen Anführungszeichen, damit $, ` und " wörtlich bleiben — auch in einem Passwort. In der Generated Crontab Line schreibt das Tool außerdem jedes % als \%, denn ein unmaskiertes % beendet in der Crontab den Befehl (der Rest wird zu dessen Eingabe). Command only zeigt den Befehl ohne diese Maskierung, so wie du ihn in der Shell testest.

Eine typische erzeugte curl-Zeile mit den Standardwerten sieht so aus:

*/15 * * * *  curl --fail -sS --max-time 30 -o /dev/null 'https://example.com/cron/run' > /dev/null 2>&1

Zugangsdaten: Trägst du einen Benutzer ein, ohne die .netrc-Option zu aktivieren, warnt das Tool, dass das Passwort in der Crontab und während des Laufs in der Prozessliste (ps) sichtbar ist. Mit aktivierter Option zeigt es stattdessen die passende ~/.netrc-Zeile für den Host der URL (machine example.com login user password …) und den Hinweis, die Datei mit chmod 600 ~/.netrc zu schützen.

Der Tab enthält außerdem einen Block Web Cron Tips mit sechs Hinweisen: die Antwort mit -o /dev/null verwerfen und -sS nutzen (Cron mailt alles, was ein Job ausgibt); die Ausgabe in eine Logdatei umleiten; die URL mit Token, IP-Restriktion oder Basic-Auth schützen; einen Timeout setzen und lange Jobs zusätzlich mit flock -n gegen Überlappung sichern; mit curl --fail bei HTTP-Fehlern scheitern und den Status bei Bedarf mit -w '\%{http_code}' protokollieren; stets HTTPS verwenden.

Reiter 3 — CMS & Frameworks

Hier liefert das Tool fertige Crontab-Rezepte für fünf Systeme, jeweils mit Copy-Button. Der Tenor überall: Den eingebauten oder pseudo-zeitgesteuerten Scheduler durch einen echten System-Cron ersetzen oder anstoßen. Die Zeilen sind für die persönliche Crontab des Webserver-Benutzers gedacht (crontab -u www-data -e) und enthalten deshalb keine Benutzerspalte — die gehört nur in /etc/crontab und Dateien unter /etc/cron.d/.

WordPress

WordPress nutzt WP-Cron, das bei Seitenaufrufen feuert — auf traffic-schwachen Seiten unzuverlässig. Empfehlung: WP-Cron in wp-config.php per define( 'DISABLE_WP_CRON', true ); abschalten und durch einen echten Cron ersetzen, bevorzugt via WP-CLI — alle fünf Minuten wp cron event run --due-now --path=/var/www/html --quiet —, alternativ via curl auf wp-cron.php?doing_wp_cron. WP-CLI ist laut Tool schneller, weil es keinen HTTP-Request braucht.

TYPO3

TYPO3 nutzt die Scheduler-Extension, die ein echter Cron anstoßen muss: alle fünf Minuten /var/www/html/vendor/bin/typo3 scheduler:run --no-ansi -v. Fehlt die Extension, installierst du sie mit composer req typo3/cms-scheduler. Das Tool weist ausdrücklich darauf hin, dass der TYPO3-Scheduler keinen HTTP-Trigger hat und nur über die CLI läuft — ohne SSH-Zugang trägst du den CLI-Befehl im Cron-Menü deines Hosters ein. Eine curl-Variante gibt es für TYPO3 deshalb nicht.

Drupal

Drupal nutzt Cron-Hooks (hook_cron()), angestoßen via Drush (alle 15 Minuten vendor/bin/drush cron --uri=https://example.com -q, empfohlen) oder per curl auf https://example.com/cron/YOUR_CRON_KEY mit dem Cron-Key (aus Administration → Configuration → System → Cron). Für volle Kontrolle empfiehlt das Tool, das eingebaute Automated Cron-Modul mit drush pm:uninstall automated_cron zu entfernen.

Laravel

Laravels Task Scheduler braucht nur eine einzige Crontab-Zeile (cd /var/www/html && php artisan schedule:run >> /dev/null 2>&1, jede Minute) — alle Aufgaben werden im Code definiert, laut Tool in app/Console/Kernel.php bzw. ab v9 in routes/console.php. Der Tab zeigt Beispiel-Task-Definitionen (dailyAt('09:00'), everyFiveMinutes(), daily()) und zum Testen schedule:run sowie den Vordergrund-Modus schedule:work (ab v8, prüft jede Minute).

Symfony

Symfony nutzt Console Commands, je Befehl eine eigene Crontab-Zeile (Beispiel: stündlich php /var/www/html/bin/console app:send-emails --no-ansi mit Ausgabe in eine Logdatei). Ab Symfony 6.3 gibt es die Scheduler-Komponente (composer require symfony/scheduler), angetrieben über einen Worker, den Cron jede Minute mit messenger:consume scheduler_default --time-limit=60 startet. Hinweis des Tools: aus Cron immer --no-ansi und --no-interaction setzen.

General Best Practices

Ein eigener Block sammelt sieben allgemeine Regeln: absolute Pfade verwenden (Cron hat ein minimales $PATH, also /usr/bin/php statt php); in /etc/crontab bzw. /etc/cron.d/ den Benutzer angeben; die Ausgabe umleiten (>> /var/log/cron.log 2>&1 oder /dev/null); gegen Überlappung locken (flock oder solo); den Befehl vorab manuell als Cron-Benutzer testen (sudo -u www-data php artisan schedule:run); cron.d gegenüber crontab bevorzugen (datei-basiert, versionierbar); und die Zeitzone beachten (CRON_TZ=Europe/Berlin am Anfang der Crontab).

Reiter 4 — Docker / DDEV

Dieser Tab sammelt Muster für Cron in Containern.

Docker & Podman

Drei Wege plus Podman:

• Option 1 — Cron im Container: im Dockerfile einen Cron-Daemon installieren (z. B. dcron auf Alpine), die crontab-Datei einkopieren und crond im Entrypoint starten. Tipp: Ausgabe nach /proc/1/fd/1 schreiben, damit sie im Docker-stdout-Log erscheint.
• Option 2 — dedizierter Cron-Container: in Docker Compose einen separaten Service mit demselben Image/Volume und command: ["crond", "-f", "-l", "2"].
• Option 3 — docker exec vom Host: der Host-Crontab ruft docker exec my_app … in den laufenden Container — bewusst ohne -t, denn aus Cron gibt es kein Terminal.
• Podman (rootless): analog per podman exec; zusätzlich loginctl enable-linger $USER, damit User-Dienste und Cron einen Logout überleben.

DDEV

Drei DDEV-Varianten plus CMS-Beispiele:

• Option 1 — Host-Cron + ddev exec: ein Eintrag in der Host-Crontab (crontab -e), der ins Projektverzeichnis wechselt und ddev exec php artisan schedule:run aufruft. Funktioniert nur, wenn das Projekt läuft (ddev start) — das Tool empfiehlt eine ddev describe | grep running-Prüfung.
• Option 2 — eigener DDEV-Service (empfohlen): .ddev/docker-compose.cron.yaml mit einem Schleifen-Container (while true; … sleep 60).
• Option 3 — DDEV-Hook (post-start): ein post-start-Hook in .ddev/config.yaml, der die Schleife im Web-Container startet; einfach, aber der Prozess endet beim Container-Neustart.
• Dazu fertige Zeilen für WordPress in DDEV (ddev wp cron event run --due-now) und TYPO3 in DDEV (ddev typo3 scheduler:run).

Ein Block Container Cron Tips ergänzt: Cron im Container nach Möglichkeit vermeiden (lieber dedizierter Container), nach stdout loggen, die Zeitzone setzen (TZ=Europe/Berlin, sonst UTC), Health-Checks nutzen und lokal (DDEV) wie in Produktion denselben Scheduler-Weg verwenden.

Reiter 5 — Reference

Ein reines Nachschlagewerk, jederzeit ohne Eingabe nutzbar:

• das oben gezeigte Syntax-Diagramm (Cron Expression Format) und die Feld-Tabelle,
• die Tabelle Special Characters (* , - /) mit drei Hinweisen: der ODER-Regel für Tag des Monats und Wochentag, dem Neustart von Schritten (*/7 → Lücke von vier Minuten) und dem Abschnitt Not in Linux cron zu Quartz-/Spring-Syntax samt Umschreibung für „letzter Tag des Monats“,
• die Spezialstring-Tabelle (Special Strings),
• eine Tabelle Common Examples mit elf häufigen Ausdrücken — von */5 * * * * bis zur Namens-Schreibweise 5 4 * * sun,
• Useful Commands: crontab -e, crontab -l, crontab -r (Vorsicht!), crontab -u www-data -e, ls /etc/cron.d/, systemctl status cron, journalctl -u cron (Cron-Log unter systemd, auf RHEL/Fedora -u crond), grep CRON /var/log/syslog (Cron-Log mit rsyslog auf Debian/Ubuntu) und run-parts --test /etc/cron.hourly (listet die stündlichen Skripte; ohne --test führt es sie aus),
• der MAILTO-Abschnitt.

MAILTO — E-Mail-Benachrichtigungen

Standardmäßig mailt Cron jede Ausgabe (stdout/stderr) eines Jobs an den lokalen Systembenutzer. Die Variable MAILTO am Anfang der Crontab steuert das:

Der Tab zeigt dazu eine Beispiel-Crontab:

MAILTO=""

*/5 * * * *  curl -s -o /dev/null "https://example.com/cron.php"
0 4 * * *   /usr/bin/backup.sh

Das Tool grenzt beide Mechanismen ab: MAILTO="" unterdrückt Mails global für die ganze Crontab, > /dev/null 2>&1 unterdrückt die Ausgabe pro Befehl und verhindert zusätzlich, dass ein Prozess an einer vollen Mail-Queue hängenbleibt. Für Web-Cron-Jobs ist die Kombination beider am robustesten.

Für die Zielgruppen und das große Bild siehe die Übersicht. Konkrete Ausdrücke stehen in den Beispielen, die typischen Fallen in den Tipps & Tricks. Ausprobieren kannst du alles direkt im Tool.