Automatisiere die Arbeit. Beweise vorher, dass sie stimmt.

Nein. Du wählst einen Auslöser, fügst Filter aus Auswahllisten hinzu und wählst Aktionen — und mit sechsundzwanzig fertigen Rezepten startest du meist bei etwas, das schon funktioniert. Bedingungen sind verschachtelte Alle/Beliebige/Keine-Gruppen mit zwölf Vergleichen, bewusst keine Formelsprache: mit einer Formel wäre „was tut diese Regel eigentlich?“ erst nach dem Ausführen zu beantworten. Webhooks und Platzhalter gibt es für den seltenen Fall, dass du weiter reichen musst, und sie sind optional.

Auf vier Wegen, bevor sie je echt läuft. Der Builder schreibt dir die ganze Regel als klaren Satz zurück, während du sie baust. Ein Probelauf führt jeden Schritt gegen ein echtes Objekt aus deinem Konto aus, ändert nichts und meldet pro Schritt, was er täte. Eine gespeicherte Regel testest du, wann du willst. Und der Backtest spielt Auslöser und Filter gegen deine eigene Ereignishistorie und sagt dir, wie oft die Regel in den letzten dreißig Tagen ausgelöst hätte — und worauf. Die meisten Regel-Engines dieser Kategorie bieten nichts davon.

In beide Richtungen. Ereignisse aus GitHub, Jira, Linear und PagerDuty starten Regeln — ein fehlgeschlagener Workflow, ein gemergter Pull Request, ein veröffentlichtes Release, ein eskalierter Vorfall — und Regeln handeln zurück: ein Issue öffnen, labeln, zuweisen, kommentieren oder schließen, einen Pull Request mergen, ein Review anfragen, einen Workflow starten oder neu starten, ein Release oder Deployment anlegen, einen Commit-Status setzen, ein Ticket verschieben oder eine Notion-Seite anlegen und kommentieren. Das sind 32 Aktionen über verbundene Konten, zusätzlich zu den 47 eingebauten.

Das hängt davon ab, wie sie fehlschlug, und genau das ist der Punkt. Ein vorübergehender Fehler wird mit wachsenden Pausen erneut versucht — 30 Sekunden, dann zwei, fünf, zehn und fünfzehn Minuten — und wenn er nie durchgeht, gibt der Lauf auf — mit festgehaltenem Grund — statt zu hängen. Eine Berechtigung, die deinem Zugang fehlt, stoppt die Regel dagegen sofort, nennt die Berechtigung so, wie der Provider sie schreibt, und benachrichtigt dich, denn vier weitere Versuche wären vier identische Absagen. Fünf fehlgeschlagene Läufe in Folge schalten eine Regel ab, mit festgehaltenem Grund. Du kannst außerdem pro Schritt sagen, dass der Lauf weitergehen soll.

Dagegen steht einiges. Bis du eine Regel speicherst und einschaltest, läuft nichts, und du kannst sie vorher als Probelauf ausführen. Alles Unumkehrbare kann hinter „Genehmigung erforderlich“ stehen, das den Lauf anhält, bis eine benannte Person zustimmt — und eine Ablehnung beendet den Lauf, statt den Schritt zu überspringen. Eine Regel handelt mit den Rechten eines echten Menschen, nicht mit einem ungebundenen Dienstaccount. Ein Lauf führt eine eingefrorene Kopie der Regel aus, eine Änderung mittendrin ändert also nichts an dem, was schon läuft. Und jeder Lauf steht im Audit-Log, mit einer gelöschten Regel, die vierzehn Tage wiederherstellbar bleibt.

Ja. Stündlich, täglich, wöchentlich, monatlich, alle N Minuten oder ein reiner Cron-Ausdruck, wenn dir das lieber ist — in der Zeitzone deiner Organisation, mit den nächsten Laufzeiten vor dem Speichern, damit du siehst, dass 09:00 nicht in der falschen Zone steht. Regeln lassen sich auch von Hand ausführen oder von einem eingehenden Webhook starten, an den jedes Tool posten kann.

Drei Regeln im kostenlosen Plan, fünfundzwanzig bei Pro und unbegrenzt bei Business — jede mit so vielen Bedingungen und Aktionen, wie du brauchst. Jede Aktion ist im kostenlosen Plan enthalten, bis auf die elf, die Server an- und ausschalten oder Cloudflare-Einstellungen ändern; die sind Pro. Laufverlauf, Probeläufe und der Backtest sind gar nicht begrenzt.