Cooldowns

Cooldowns verhindern, dass eine Automation zu oft hintereinander feuert. Praxisbeispiel: Du hast eine Sub-Sound-Automation, jemand verschenkt 50 Subs auf einmal — ohne Cooldown krachen 50 Sounds übereinander und drücken den Stream-Ton runter.

Technisch laufen Cooldowns über einen atomaren Claim-vor-Ausführung-Mechanismus (nicht über eine einfache Zeitstempel-Prüfung): Der Worker versucht, den Cooldown-Slot für die Regel zu „claimen", bevor die Actions laufen. Gewinnt der Claim, läuft die Regel; verliert er (weil der Slot noch belegt ist), wird der komplette Lauf als cooldown_skip geloggt und keine einzige Action ausgeführt. Schlägt eine Action danach fehl, wird der Claim wieder freigegeben (release) — ein technischer Fehler „verbrennt" also keinen Cooldown-Slot unnötig.

Die Cooldown-Scopes

Es gibt mehr als nur „global/pro User/pro Channel". Der reale Scope-Katalog im CooldownStore:

Scope	Wirkung
`global`	Die Automation kann insgesamt nur alle X Sekunden feuern, egal wer triggert. Das ist das Standard-Feld `cooldown_sec` im Editor.
`channel`	Pro Twitch-Channel. Bei Multi-Channel-Automations relevant; bei einem einzelnen Kanal praktisch identisch zu `global`.
`viewer`	Pro Zuschauer (Twitch-User-ID des Chatters), dauerhaft — überlebt Stream-Restarts.
`viewer_stream`	Pro Zuschauer, aber nur für die aktuelle Stream-Session — reset bei neuem Stream.
`viewer_day`	Pro Zuschauer, einmal pro Kalendertag.
`viewer_ever`	Pro Zuschauer, effektiv einmalig für immer (intern über eine sehr lange TTL gelöst, nicht über ein echtes „permanent"-Flag — läuft also nicht in absehbarer Zeit ab).
`command`	Pro exaktem Befehlstext (kleingeschrieben) — nützlich, wenn eine Regel auf mehrere Chat-Befehle reagiert und du sie getrennt drosseln willst.
`user`	Selten genutzt: Cooldown auf Ebene des Chatlix-Accounts, nicht des Twitch-Viewers.

Im Editor bekommst du die praxisrelevanten Fälle als zwei Felder: das globale cooldown_sec (Scope global) direkt an der Regel, plus einen separaten, granulareren Block „Pro Zuschauer", der intern als user_cooldown_json gespeichert wird und dir viewer/viewer_stream/viewer_day/viewer_ever als Auswahl anbietet — je nachdem, ob du „alle X Sekunden", „einmal pro Stream", „einmal pro Tag" oder „einmal überhaupt" willst.

Wo du das einstellst

Im Automation-Editor (/dashboard/automations → Regel öffnen) unter dem Abschnitt Cooldowns:

Globaler Cooldown — ein Sekundenfeld, leer/0 = kein Cooldown.
Pro-Zuschauer-Sperre — Dropdown für den Zeitraum (alle N Sekunden / einmal pro Stream / einmal pro Tag / einmal überhaupt) + Sekundenwert, falls zutreffend.

Typische Werte

Sub-Sound: global = 5 s. Damit klingen Mass-Gift-Subs wie ein angenehmer Schauer, nicht wie ein Wasserfall. Noch sauberer: nutze direkt den Trigger gift_bomb (feuert einmalig, wenn 5+ Gift-Subs in 30 s reinkommen) statt sub/gift_sub + Cooldown zu kombinieren.
Chat-Befehl !song: Pro-Zuschauer-Sperre viewer, 60 s. Stammzuschauer können trotzdem alle paar Minuten neu anfragen, aber niemand spammt.
Cheer-Konfetti: global = 30 s. Sieht auch bei vielen kleinen Cheers entspannt aus.
Discord-Webhook „Live-Ankündigung": global = 3600 s (1 h). Verhindert doppelte Pings, falls Stream-Online zweimal hintereinander getriggert wird.
Erst-Follower-Begrüßung: Pro-Zuschauer-Sperre viewer_ever — jeder Follower bekommt die Sonder-Ansage genau einmal, nie wieder, egal wie oft er später erneut followt/entfollowt.
Tages-Bonus per Chat-Befehl: viewer_day — genau einmal pro Kalendertag pro Zuschauer.

Was passiert, wenn ein Cooldown greift

Im Run-Log (/dashboard/automation-runs) taucht ein Eintrag mit Status cooldown_skip auf. Der Trigger ist aufgezeichnet, aber keine Action wurde ausgeführt. So siehst du auch im Nachhinein, wann der Cooldown gegriffen hat — wichtig für Tuning.

Der Trigger wird nicht in eine Warteschlange gepackt. Wenn der Cooldown abläuft, läuft die Automation nicht „nachträglich" für den verpassten Trigger an. Das ist Absicht (sonst hättest du nach einem 50-Gift-Sub-Burst eine Sound-Lawine, die Minuten später nachläuft).

Globaler vs. Action-Cooldown

Der Standard-Cooldown wirkt auf die ganze Automation, nicht auf einzelne Actions in ihr. Willst du nur eine einzelne Action innerhalb einer Regel drosseln, ohne die restlichen Actions zu blockieren, nutzt du condition_expr mit cooldown_active/cooldown_not_active als Condition-Typ auf genau dieser Action (Power-Feature), oder du lagerst die kritische Action in eine eigene Automation aus, die per webhook_send/webhook_received von der Haupt-Automation angestoßen wird. Für die meisten Fälle reicht aber: zwei getrennte Automations mit demselben Trigger und unterschiedlichen Cooldowns (siehe Beispiel unten).

Cooldown + Burst-Schutz

Für Bit-Bursts (jemand cheered 5× hintereinander in 10 Sekunden) gibt es zusätzlich einen internen Anti-Burst-Schutz auf Queue-Ebene: dieselbe Action wird nicht öfter als ~1×/Sekunde an OBS/Browser-Source geschickt, selbst wenn die Automation rein logisch öfter feuern dürfte. Das siehst du nicht im Editor, läuft automatisch und schützt die Render-Engine.

Cooldown-Reset

Im Editor gibt es einen « Cooldown-Reset »-Button. Praktisch beim Testen: löscht die laufenden Cooldown-Einträge für diese Automation, sodass der nächste Trigger sofort durchgeht.

Persistenz: global/channel/viewer-Cooldowns überleben einen Stream-Restart. Nur der Scope viewer_stream ist explizit an die aktuelle Stream-Session gebunden und setzt sich beim nächsten Stream-Start zurück.

Beispiel-Setup: Mass-Gift-Sub-Welcome

Szenario: Jemand verschenkt 25 Subs auf einmal. Twitch feuert 25 einzelne gift_sub-Events. Du willst:

Nicht 25× den Sub-Sound spielen.
Aber jedem geschenkten User eine Punkte-Belohnung geben.

Lösung: zwei Automations.

Sub-Sound → Trigger gift_sub (oder besser: gift_bomb) → global cooldown = 5 s. Spielt max. alle 5 s einen Sound. Bei 25 Mass-Gift-Subs: 1 Sound, der Rest wird cooldown_skip.
Punkte-Bonus → Trigger gift_sub → kein Cooldown. Action: add_points +10 für {user}. Läuft 25×, jeder Gift-Empfänger kriegt seinen Bonus.

Getrennte Cooldowns für unterschiedliche Ziele in getrennten Regeln — das ist der Hebel.

Was Cooldowns nicht ersetzen

Twitch-Reward-Limits: laufen in Twitch und sind separat. Willst du Channel-Points-Rewards limitieren, mach das in Twitch (siehe Buch Rewards).
OBS-Drosselung: hat ihre eigene 1/s-Bremse für Szenenwechsel/Actions (siehe Burst-Schutz oben).
Externe API-Rate-Limits: dein Discord-Webhook hat eigene Limits — die Automation umgeht die nicht.
Plan-Limits (Anzahl Automations, Actions pro Regel): das ist ein separates Thema, siehe Seite Automations Grundlagen, Abschnitt „Plan-Limits".

Diagnose

Wenn eine Automation seltener läuft als erwartet:

In /dashboard/automation-runs auf status = cooldown_skip filtern. Wenn da viele Einträge sind, ist der Cooldown zu streng eingestellt.
Bei einer Pro-Zuschauer-Sperre prüfen, dass der User-Bezug im Trigger überhaupt existiert. Trigger ohne User-Bezug (z. B. stream_online, timer) sollten keine Pro-Zuschauer-Sperre nutzen — die greift dort nicht sinnvoll, weil es keinen „Zuschauer" im Event gibt.
Läuft eine Regel dauerhaft in Fehler statt in Cooldown, kann disabled_by_system gegriffen haben (siehe Seite Erste Automation bauen, Abschnitt Debugging) — das ist kein Cooldown-Problem, sondern ein automatischer Selbstschutz gegen kaputte Regeln.

Siehe auch

Automations Grundlagen — Übersicht, Trigger-/Action-Katalog, Plan-Limits.
Erste Automation bauen — Run-Status-Werte und Debugging.
Automation-Templates — viele Templates haben sinnvolle Default-Cooldowns vorkonfiguriert.