> ## Documentation Index > Fetch the complete documentation index at: https://docs.devin.ai/llms.txt > Use this file to discover all available pages before exploring further. # Automatisierungen > Richten Sie Devin-Automatisierungen ein: ereignisgesteuerte Workflows, die Devin-Sitzungen über Slack, GitHub, Linear, Zeitpläne und Webhooks starten. Mit Automatisierungen können Sie externe Ereignisse — Slack-Nachrichten, GitHub-Webhooks, Linear-Ticket-Updates, Zeitpläne und benutzerdefinierte Webhooks — mit Devin-Sitzungen verknüpfen, die automatisch starten. Anstatt Devin jedes Mal manuell zu markieren, wenn ein Fehler gemeldet wird oder eine CI-Prüfung fehlschlägt, definieren Sie den Trigger einmal und Devin verarbeitet jedes Ereignis automatisch, sobald es eintrifft. Sie können Automatisierungen auch deklarativ mit dem [Terraform-Anbieter](/de/api-reference/terraform-provider) verwalten. Eine Videoanleitung mit vier Beispielen finden Sie im [Tutorial zu Devin-Automatisierungen](/de/tutorial-library/automations).

Kernkonzepte

Eine Automatisierung besteht aus einem Auslöser und Aktionen sowie optionalen Bedingungen und einer Preflight-Prüfung: | Teil | Was er macht | | - | - | | **Auslöser** | Das Ereignis, das die Automatisierung auslöst (z. B. eine Slack-Nachricht in `#bugs`, ein fehlgeschlagener GitHub-CI-Lauf, eine Änderung eines Linear-Labels) | | **Bedingungen** | Optionale Filter, die den Auslöser eingrenzen (z. B. nur auslösen, wenn das Label `bug` ist, oder nur für ein bestimmtes Repo) | | **Preflight-Prüfung** | Ein optionales Skript, das ausgeführt wird, sobald ein Ereignis zutrifft, und zwar vor den Aktionen. Es kann das Ereignis überspringen, durchlassen oder in separate Arbeitseinträge aufteilen. | | **Aktion** | Was Devin tut, wenn der Auslöser eintritt — eine neue Sitzung starten, einer bestehenden Sitzung eine Nachricht senden oder als Triage-Monitor agieren |

Aktionstypen

| Aktion | Beschreibung | | - | - | | **Sitzung starten** | Erstellt eine neue Devin-Sitzung mit dem von Ihnen definierten Prompt. Die Event-Payload wird automatisch als Kontext hinzugefügt. | | **Nachricht an eine Sitzung** | Sendet eine Nachricht an eine vorhandene, lang laufende Devin-Sitzung — nützlich, um Ereignisse in eine Sitzung einzuspeisen, die ihren Zustand beibehält. | | **Triage Devin** | Ein persistenter Devin, der einen Slack-Channel überwacht. Er prüft jede eingehende Nachricht, entscheidet, was Aufmerksamkeit erfordert, und startet untergeordnete Sub-Devins für Einträge, die weiter untersucht werden müssen. Weitere Informationen finden Sie unter [Auto-Triage](/de/product-guides/auto-triage). | | **E-Mail-Benachrichtigung** | Sendet Ihnen eine E-Mail, wenn die Automatisierung ausgeführt wird — bei jeder Ausführung, nur bei Fehlern oder nur bei erfolgreichen Ausführungen. |

Trigger-Quellen

| Quelle | Ereignistypen | Beispielanwendungsfall | | - | - | - | | **Slack** | Neue Nachricht, Reaktion hinzugefügt | Fehlerberichte in `#incidents` triagieren, mit 🚨 reagieren, um eine Untersuchung zu starten | | **GitHub** | Issue, Issue-Kommentar, PR geöffnet/aktualisiert, PR-Review, Check-Lauf (CI), Push | CI-Fehlschläge automatisch beheben, auf `/devin`-Kommentare in Issues reagieren | | **GitLab** | Merge Request, MR-Kommentar, Issue, Issue-Kommentar, Push, Pipeline | Fehlgeschlagene Pipelines automatisch beheben, auf Kommentare in Merge Requests reagieren | | **Linear** | Issue erstellt, Label hinzugefügt, Status geändert, Priorität geändert, zugewiesen, in ein Team verschoben | Fehler nach dem Hinzufügen eines Labels triagieren, Tickets umsetzen, wenn sie Devin zugewiesen werden | | **Jira** | Issue erstellt, Issue aktualisiert, Label hinzugefügt, Status geändert, zugewiesen, kommentiert | Tickets umsetzen, wenn sie Devin zugewiesen werden, Statusänderungen verfolgen | | **Pylon** | Issue erstellt, Tag hinzugefügt, Status geändert | In Pylon eingereichte Kunden-Fehlertickets triagieren. Siehe die [Pylon-Integration](/de/integrations/pylon) | | **PagerDuty** | Incident ausgelöst, bestätigt, behoben, aktualisiert | Incidents mit hoher Dringlichkeit untersuchen, sobald sie ausgelöst werden. Siehe die [PagerDuty-Integration](/de/integrations/pagerduty) | | **Zeitplan** | Wiederkehrend (cron-basiert) oder einmalig (einmal ausführen) | Tägliche Sentry-Fehlerprüfungen, wöchentliche Abhängigkeits-Updates, nächtliche Smoke-Tests oder eine einmalige Aufgabe, die zu einem bestimmten zukünftigen Zeitpunkt ausgeführt wird | | **Webhook** | Eingehende HTTP-Anfrage | Beliebige externe Systeme (PagerDuty, Datadog, Sentry, benutzerdefinierte Tools) über eine Webhook-URL mit Devin verbinden | Alle Quellen außer Zeitplänen erscheinen in der Trigger-Auswahl, sobald die entsprechende Integration unter **Settings > Connections** verbunden ist. Eine einzelne Automatisierung kann **mehrere Trigger** haben — sie sind mit ODER verknüpft, sodass die Automatisierung ausgelöst wird, wenn einer ihrer Trigger zutrifft. Zum Beispiel können Sie eine Automatisierung einrichten, die sowohl bei einem fehlgeschlagenen GitHub-CI-Lauf als auch bei einer Slack-Reaktion ausgelöst wird.

Automatisierung erstellen

Auf der Seite „Automatisierungen“

1. Gehen Sie in der Seitenleiste zu **Automatisierungen** 2. Klicken Sie auf **Automatisierung erstellen** und wählen Sie **Create**, um einen leeren Editor zu öffnen (falls Sie noch keine Automatisierungen haben, klicken Sie stattdessen auf der Startseite auf **Create manually**). Dasselbe Menü bietet außerdem **Vorlage** (öffnet die Vorlagengalerie) und **Generate with Devin** (startet eine Sitzung, in der die Automatisierung gemeinsam mit Ihnen erstellt wird) 3. Konfigurieren Sie den Auslöser, die Bedingungen und die Aktion 4. Klicken Sie auf **Automatisierung erstellen**

Aus einer Vorlage

1. Gehen Sie in der Seitenleiste zu **Automatisierungen** 2. Klicken Sie auf **Automatisierung erstellen** > **Vorlage** (falls Sie noch keine Automatisierungen haben, klicken Sie stattdessen auf der Startseite auf **Aus Vorlage erstellen**) oder rufen Sie direkt `/automations/templates` auf 3. Durchsuchen Sie die Vorlagengalerie — jede Vorlage ist eine vorkonfigurierte Automatisierung für einen gängigen Workflow 4. Klicken Sie auf eine Vorlage, um den Editor mit dem Auslöser, der Aktion und den vorgeschlagenen Limits der Vorlage vorab auszufüllen 5. Passen Sie die Konfiguration an (z. B. wählen Sie Ihren Slack Channel oder Ihr Repo aus) und klicken Sie auf **Automatisierung erstellen**

Mit natürlicher Sprache

Klicken Sie auf der Seite „Automatisierungen“ auf **Create automation** > **Generate with Devin** (falls Sie noch keine Automatisierungen haben, klicken Sie stattdessen auf der Startseite auf die Karte **Generate with Devin**). Devin öffnet eine neue Sitzung, um Ihnen beim Erstellen der Automatisierung zu helfen. Beschreiben Sie, was Sie möchten — zum Beispiel: „Wenn ein CI-Check in my-org/my-repo fehlschlägt, soll Devin das Problem beheben und in denselben Branch pushen.“ Devin generiert dann die Konfiguration der Automatisierung, die Sie prüfen und erstellen können.

Trigger konfigurieren

Slack-Trigger

Slack-Trigger werden ausgelöst, wenn in einem Channel, in den Devin eingeladen wurde, eine Nachricht gepostet oder eine Reaktion hinzugefügt wird. * **Slack-Nachricht**: Wird bei neuen Nachrichten ausgelöst. Standardmäßig wird eine Channel-Bedingung hinzugefügt; Sie können sie entfernen, um Nachrichten über mehrere Channels hinweg zu erfassen, allerdings benötigt dann jede Bedingungsgruppe mindestens einen weiteren Filter (zum Beispiel Nachrichtentext oder Absendertyp — **Include thread replies** allein genügt nicht). * **Nutzergruppe erwähnt**: Wird ausgelöst, wenn eine Slack-Nutzergruppe (zum Beispiel `@oncall`) erwähnt wird. Wählen Sie die Gruppe aus oder geben Sie ihre Slack-ID ein (beginnt mit `S`), und beschränken Sie den Trigger optional auf bestimmte Channels. * **Slack-Reaktion**: Wird ausgelöst, wenn eine bestimmte Emoji-Reaktion zu einer Nachricht hinzugefügt wird (z. B. 🚨 für Incidents). Sie können nach dem Namen der Reaktion und dem Channel filtern. Bei Channel-bezogenen Triggern muss Devin in den Slack-Channel eingeladen werden. Außerdem müssen Sie Ihr persönliches Slack-Konto in **Settings > Connections > Slack** verbunden haben.

GitHub-Trigger

GitHub-Trigger werden durch Repository-Ereignisse ausgelöst. Sie müssen für jeden Trigger ein bestimmtes Repository auswählen. * **Issue**: Wird bei Issue-Ereignissen ausgelöst (geöffnet, geschlossen, wieder geöffnet, bearbeitet, mit Label versehen). * **Issue-Kommentar**: Wird ausgelöst, wenn ein Kommentar zu einem GitHub-Issue veröffentlicht wird. Wird häufig mit einer `starts_with "/devin"`-Bedingung verwendet, damit Nutzer in jedem Issue `/devin` eingeben können, um Devin auszulösen. * **Pull Request**: Wird bei PR-Ereignissen ausgelöst (geöffnet, synchronisiert usw.). * **Pull-Request-Review**: Wird ausgelöst, wenn ein Review für eine PR eingereicht wird. * **Pull-Request-Review-Kommentar**: Wird bei einzelnen Review-Kommentaren ausgelöst. * **Check-Lauf (CI)**: Wird ausgelöst, wenn eine CI-Prüfung abgeschlossen ist. Filtern Sie nach `conclusion = failure`, um fehlerhafte Builds automatisch zu beheben. * **Push**: Wird bei Pushes auf einen Branch ausgelöst. Standardmäßig werden GitHub-Automatisierungen nur in privaten Repositories ausgelöst. Ein Admin kann eine einzelne GitHub-Verbindung für öffentliche Repositories aktivieren: Öffnen Sie in [Settings → Connections → GitHub](https://app.devin.ai/settings/connections/github) das Menü der Verbindung und setzen Sie **Automation scope** auf **All installed repos**. Jeder im Internet kann ein öffentliches Repo kommentieren oder eine PR dafür öffnen. Daher bergen Trigger für öffentliche Repos ein höheres Risiko für Prompt-Injection — aktivieren Sie dies bewusst und halten Sie Ihre Trigger-Bedingungen eng.

GitLab-Trigger

GitLab-Trigger reagieren auf Projektereignisse in deiner verbundenen GitLab-Instanz: * **Merge Request**: Wird bei MR-Aktionen ausgelöst (geöffnet, geschlossen, gemergt, wieder geöffnet, genehmigt, aktualisiert). * **MR-Kommentar**: Wird ausgelöst, wenn ein Kommentar (Note) an einem Merge Request veröffentlicht wird, einschließlich Diff-Review-Threads. * **Issue**: Wird bei Issue-Aktionen ausgelöst (geöffnet, geschlossen, wieder geöffnet, aktualisiert). * **Issue-Kommentar**: Wird ausgelöst, wenn ein Kommentar an einem Issue veröffentlicht wird. * **Push**: Wird bei Pushes auf einen Branch ausgelöst. * **Pipeline**: Wird ausgelöst, wenn eine Pipeline einen bestimmten Status erreicht — filtere nach Status (z. B. `failed`), um fehlgeschlagene Pipelines automatisch zu beheben.

Linear-Trigger

Linear-Trigger werden bei Issue-Ereignissen in Ihrem verbundenen Linear-Workspace ausgelöst. Sie müssen für jeden Trigger ein Team auswählen. * **Issue erstellt**: Wird ausgelöst, wenn im ausgewählten Team ein neues Issue erstellt wird. * **Label hinzugefügt**: Wird ausgelöst, wenn einem Issue ein Label hinzugefügt wird (z. B. `bug`, `devin`). * **Status geändert**: Wird ausgelöst, wenn sich der Status eines Issues ändert (z. B. zu „In Progress“ verschoben). * **Priorität geändert**: Wird ausgelöst, wenn sich die Priorität eines Issues ändert. * **Zugewiesen**: Wird ausgelöst, wenn ein Issue einer Person zugewiesen wird. * **Issue verschoben**: Wird ausgelöst, wenn ein Issue in ein anderes Team verschoben wird – der Team-Filter des Triggers bezieht sich dabei auf das Zielteam.

Jira-Trigger

Jira-Trigger werden durch Issue-Ereignisse in deiner verbundenen Jira-Site ausgelöst. Du kannst nach Projekt, Labels, Status, zugewiesener Person und Epic filtern: * **Issue erstellt**: Wird ausgelöst, wenn ein neues Issue erstellt wird. * **Issue updated**: Wird ausgelöst, wenn sich die Felder eines Issues ändern. * **Label hinzugefügt**: Wird ausgelöst, wenn einem Issue ein Label hinzugefügt wird. * **Status geändert**: Wird ausgelöst, wenn sich der Status eines Issues ändert. * **Zugewiesen**: Wird ausgelöst, wenn ein Issue jemandem zugewiesen wird. * **Comment created or edited**: Wird ausgelöst, wenn ein Kommentar zu einem Issue hinzugefügt oder bearbeitet wird.

Zeitplan-Trigger

Zeitplan-Trigger werden nach einem zeitbasierten Zeitplan ausgeführt — entweder wiederkehrend oder als einmaliger Lauf. Erweitern Sie im Trigger-Dropdown **Zeitplan** und wählen Sie **Jede Stunde**, **Jeden Tag**, **Jede Woche**, **Einmal ausführen** oder **Benutzerdefinierter Zeitplan**. * **Wiederkehrend**: Legen Sie die Häufigkeit (stündlich, täglich, wöchentlich) und die Uhrzeit fest. Intern verwenden Zeitpläne das iCalendar-RRULE-Format. Wählen Sie **Benutzerdefinierter Zeitplan**, um eine benutzerdefinierte Wiederholung zu erstellen (Wiederholung alle N Minuten/Stunden/Tage/Wochen/Monate), oder geben Sie direkt einen RRULE-String ein (z. B. `FREQ=WEEKLY;BYDAY=MO;BYHOUR=9;BYMINUTE=0`), um komplexere Zeitpläne abzubilden. * **Einmal ausführen**: Wird einmalig zu einem bestimmten zukünftigen Datum und einer bestimmten Uhrzeit ausgelöst und danach automatisch deaktiviert. Nützlich für einmalige verzögerte Aufgaben — z. B. „Wecke Devin in 12 Stunden auf, um eine Aufgabe auszuführen.“ Wählen Sie Datum und Uhrzeit aus (standardmäßig eine Stunde ab jetzt); der Zeitpunkt muss in der Zukunft liegen. Jeder Zeitplan hat eine eigene Zeitzone, die standardmäßig der Zeitzone Ihres Browsers entspricht und im Zeitplan-Editor geändert werden kann. Der Zeitplan wird zu dieser lokalen Uhrzeit ausgeführt, auch über Zeitumstellungen (Sommer-/Winterzeit) hinweg.

Webhook-Trigger

Mit Webhook-Triggern können Sie jedes externe System über einen eindeutigen HTTPS-Endpunkt mit Devin verbinden. 1. Erstellen Sie eine Automatisierung mit einem **Webhook**-Trigger 2. Kopieren Sie die in der Trigger-Konfiguration angezeigte Webhook-URL und das Secret 3. Konfigurieren Sie Ihr externes System (PagerDuty, Datadog, Sentry oder jedes benutzerdefinierte Tool) so, dass es HTTP-POST-Anfragen an diese URL sendet 4. Fügen Sie optional einen **Payload-Filter** hinzu — ein Regex-Muster, dem der Request-Body entsprechen muss, damit die Automatisierung ausgelöst wird Übermitteln Sie das Webhook-Secret auf eine der folgenden Arten: * `X-Webhook-Secret: `-Header * `Authorization: Bearer `-Header * `?secret=`-Abfrageparameter Verwenden Sie bevorzugt einen Header — Abfragezeichenfolgen werden häufig in Zugriffsprotokollen von Proxys, CDNs und Servern erfasst. Die Webhook-Payload wird dem Prompt der Devin-Sitzung als Kontext hinzugefügt. Payloads mit mehr als 200 KB werden automatisch gekürzt.

Webhook-Secret

Jeder Webhook-Trigger verfügt über ein Secret zur Authentifizierung eingehender Anfragen – Aufrufe ohne das korrekte Secret werden abgelehnt. Das Secret wird für Sie generiert und angezeigt, wenn Sie den Webhook-Trigger im Automatisierungseditor hinzufügen. Kopieren Sie das Secret, sobald es angezeigt wird – es wird nicht erneut angezeigt. Ein verlorenes Secret kann nicht wiederhergestellt werden; generieren Sie stattdessen ein neues. Jede Anfrage muss das Secret im HTTP-Header `X-Webhook-Secret` enthalten. Zum Testen mit curl: ```bash theme={null} curl -X POST '' \ -H 'Content-Type: application/json' \ -H 'X-Webhook-Secret: ' \ -d '{"test": true}' ``` Wenn Sie das Secret verlieren oder rotieren müssen, öffnen Sie den Webhook-Trigger im Automatisierungseditor und generieren Sie ein neues. Das alte Secret ist sofort ungültig. Aktualisieren Sie daher Ihr externes System mit dem neuen Wert.

Preflight-Checks

Ein **Preflight-Check** ist ein optionales Skript, das zwischen einem zutreffenden Auslöser und den Actions der Automatisierung ausgeführt wird. Setzen Sie es ein, wenn die Bedingungen des Auslösers allein nicht ausreichen: Prüfen Sie zum Beispiel, ob ein Alarm noch aktiv ist, bevor Devin gestartet wird, oder pollen Sie einen externen Dienst nach einem Zeitplan und starten Sie für jedes neue Element eine Sitzung. Das Skript wird in einer separaten, kurzlebigen virtuellen Maschine (VM) ausgeführt, nicht innerhalb der Devin-Sitzung, die es gegebenenfalls startet. Es kann das Ereignis lesen, zwischen Ausführungen einen kleinen Zustand speichern und entscheiden, welche Aufgaben an die konfigurierten Actions weitergegeben werden. Preflight-Checks werden schrittweise eingeführt. Wenn **Add a step before the agent runs** in Ihrem Automatisierungs-Editor nicht angezeigt wird, ist die Funktion für Ihre Organisation noch nicht aktiviert.

Einen Preflight-Check konfigurieren und testen

1. Erstellen Sie eine Automatisierung oder bearbeiten Sie eine bestehende, und konfigurieren Sie deren Auslöser und Bedingungen. 2. Klicken Sie unterhalb des Auslöser-Abschnitts auf **Add a step before the agent runs**. Daraufhin öffnet sich die Karte **Before the agent runs**. 3. Klicken Sie auf **Edit script**, wählen Sie im Laufzeit-Auswahlfeld **Python**, **Node** (JavaScript) oder **Bash** aus und passen Sie das Vorlagenskript an. 4. Verwenden Sie bei Bedarf **Select secrets** im Skript-Editor, um Secrets der Organisation anzuhängen. Nur die ausgewählten Secrets werden als Umgebungsvariablen bereitgestellt. Zum Speichern oder Testen eines Skripts mit angehängten Secrets benötigen Sie die Berechtigung zum Verwalten von Organisations-Secrets. 5. Legen Sie in der Karte **Timeout (seconds)** fest: Der Standardwert beträgt 60 Sekunden, zulässig sind 1–300 Sekunden. Das Skript verwendet standardmäßig die **Minimal environment**; sind Machine Snapshots verfügbar, können Sie über das Auswahlfeld **Environment** auch einen Snapshot der Organisation mit Ihren Abhängigkeiten auswählen. 6. Wählen Sie im Skript-Editor unter **Test against** ein Ereignis aus und klicken Sie auf **Run**. Sie können das nicht gespeicherte Skript mit einem Beispiel eines konfigurierten Auslösers testen oder – bei einer bestehenden Automatisierung – mit einem aktuellen Ereignis. Prüfen Sie das Ergebnis, die Logs und bei ausgegebenen Einträgen die Vorschau, wie viele davon ausgeführt würden, Duplikate wären oder zurückgestellt würden. 7. Klicken Sie auf **Save script**, um die Änderungen im Editor zu übernehmen. Klicken Sie anschließend auf **Create automation** oder speichern Sie die Automatisierung, um die Konfiguration dauerhaft zu sichern. Testläufe führen zwar Ihr Skript aus, jedoch weder die Actions der Automatisierung. Außerdem werden keine Änderungen an deren gespeichertem Zustand übernommen und ausgegebene Einträge nicht als bearbeitet markiert. Externe Anfragen oder Nebeneffekte Ihres Skripts finden jedoch tatsächlich statt. Wenn Sie zum Beispiel ein Skript testen, das in einen externen Dienst schreibt, wird dieser Schreibvorgang tatsächlich ausgeführt. Die Schaltfläche **Run now** der Automatisierung umgeht Preflight und führt die konfigurierten Actions direkt aus. Verwenden Sie zum Testen des Skripts stattdessen **Test against → Run** unter **Edit script**.

Ein- und Ausgabe des Skripts

Das Skript erhält die folgenden Umgebungsvariablen. Jede davon enthält einen Dateipfad, nicht die JSON-Daten selbst: | Variable | Inhalt | | - | - | | `EVENT_FILE` | Schreibgeschütztes JSON-Event mit `event_type`, `source`, `payload` und `received_at`. Die Struktur von `payload` hängt vom Auslöser ab. | | `STATE_FILE` | Ein les- und schreibbares JSON-Objekt (bis zu 64 KiB), das zwischen erfolgreichen Live-Ausführungen erhalten bleibt. Verwenden Sie es für einen Polling-Cursor, nicht als Datenbank. | | `LAST_RUN_FILE` | Schreibgeschütztes Feedback zu zuvor ausgegebenen Einträgen: deren `key`, `status` und, falls vorhanden, `session_id`. Es enthält bis zu 200 der neuesten Einträge sowie einen `truncated`-Indikator. | | `OUTPUT_FILE` | Die JSON-Entscheidung, die Ihr Skript schreiben muss, bevor es sich erfolgreich beendet. | Schreiben Sie entweder `run` oder `items` (nicht beides) in `OUTPUT_FILE`, optional zusammen mit einem String `reason`: | Ausgabe | Verhalten | | - | - | | `{"run": true}` | Führt die konfigurierten Actions einmal mit dem ursprünglichen Event aus. | | `{"run": false, "reason": "Alert already resolved"}` | Überspringt das Event, ohne die zugehörigen Actions auszuführen. | | `{"items": [{"id": "INC-1", "title": "Investigate error spike"}]}` | Führt die konfigurierten Actions für jeden akzeptierten Eintrag einzeln aus. Mit **Start session** wird pro Eintrag eine Sitzung gestartet; jede Sitzung erhält das ursprüngliche Event und zusätzlich den jeweiligen Eintrag als Kontext. | | `{"items": []}` | Überspringt das Event, da nichts zu tun ist. | Dieses Python-Skript lässt zum Beispiel eine Slack-Nachricht nur dann durch, wenn ihr Text `urgent` enthält: ```python theme={null} import json import os with open(os.environ["EVENT_FILE"]) as f: event = json.load(f) text = event.get("payload", {}).get("text", "") should_run = "urgent" in text.lower() with open(os.environ["OUTPUT_FILE"], "w") as f: json.dump({"run": should_run, "reason": "Urgency filter"}, f) ``` Wählen Sie unter **Test against** ein Slack-Nachrichtenbeispiel oder eine aktuelle Slack-Nachricht aus, um das Ergebnis zu prüfen. Es genügt nicht, eine Entscheidung auf der Standardausgabe auszugeben: Das Skript muss gültiges JSON in `OUTPUT_FILE` schreiben und mit Exit-Code 0 beendet werden.

Einträge, Zustand und Limits

* **Vermeidung von Duplikaten:** Die `id` eines Eintrags identifiziert eine Arbeitseinheit innerhalb dieser Automatisierung, nicht nur eine Entität. `{"id": "INC-1"}` wird nur einmal verarbeitet; fügen Sie eine `version` hinzu, etwa den Update-Zeitstempel aus dem Quellsystem, um ein erneutes Auftreten dieses Vorfalls zu verarbeiten. Ohne `id` identifiziert Preflight den Eintrag über einen Hash seines Inhalts, sodass eine Änderung des Inhalts einen weiteren Lauf auslösen kann. * **Obergrenze für Einträge pro Lauf:** Standardmäßig werden pro Lauf höchstens 10 neue Einträge verteilt; die systemweite Obergrenze liegt bei 50. Einträge, die über die Obergrenze hinausgehen, werden nicht verarbeitet und auch nicht automatisch eingeplant. Ihr nächster Skriptlauf muss sie erneut ausgeben. Setzen Sie einen Cursor nicht hinter zurückgestellte Arbeit, nur weil diese in Ihrer Ausgabe enthalten war. * **Frühere Ergebnisse:** Verwenden Sie `LAST_RUN_FILE`, um zwischen laufender, erfolgreicher, fehlgeschlagener und übersprungener Arbeit zu unterscheiden. Ein Eintrag, dessen Lauf fehlschlägt, wird freigegeben, sodass ein späterer Skriptlauf ihn erneut ausgeben kann. * **Persistenter Zustand:** Live-Skriptläufe einer Automatisierung werden nacheinander ausgeführt. Fehlgeschlagene Skripte schreiben den gespeicherten Zustand nicht fort und markieren keine Einträge als verarbeitet. **Clear state** löscht sowohl den gespeicherten JSON-Zustand als auch den Verlauf bereits verarbeiteter Einträge; zuvor verarbeitete Einträge können nach dem Zurücksetzen erneut ausgeführt werden. * **Größenlimits:** Skriptquelle und Ausgabe sind jeweils auf 256 KiB begrenzt, der gespeicherte Zustand auf 64 KiB und erfasste Logs auf 1 MiB. * **Fehler:** Ein Exit-Code ungleich null, ein Timeout, eine ungültige Ausgabe bzw. ein ungültiger Zustand oder ein Infrastrukturfehler bricht das betreffende Ereignis ab, bevor seine Actions ausgeführt werden. Das Skript wird für dieses Ereignis nicht automatisch wiederholt; ein späterer Auslöser kann es erneut ausführen. * **Netzwerkzugriff:** Die VM des Skripts unterliegt den Netzwerkbeschränkungen der Automatisierung und dem jeweils geltenden [Security Profile](/de/product-guides/security-profiles). Zum Beispiel muss der Host eines externen Alert-Dienstes zugelassen sein, damit dieser gepollt werden kann. Das Anhängen eines Secrets gewährt keinen Netzwerkzugriff.

Actions konfigurieren

Sitzung starten

Die häufigste Aktion. Wenn der Trigger ausgelöst wird, startet Devin eine neue Sitzung mit Ihrem Prompt. Die Event-Payload (z. B. der Text einer Slack-Nachricht, der GitHub-Webhook-Body oder die Details eines Linear-Tickets) wird automatisch an den Prompt angehängt, damit Devin den vollständigen Kontext hat. Optionen: * **Prompt**: Die Anweisungen, denen Devin folgt. Formulieren Sie ihn so, wie Sie einen normalen Devin-Prompt schreiben würden. * **Playbook** (optional): Verwenden Sie `@playbook-name` in Ihrem Prompt, um ein [Playbook](/de/product-guides/using-playbooks) für zusätzliche Anweisungen einzubinden. * **Tags** (optional): Fügen Sie den durch diese Automatisierung erstellten Sitzungen Tags hinzu, damit sie sich leichter filtern lassen.

Nachricht an eine Sitzung

Sendet eine Nachricht an eine bestehende, lang laufende Devin-Sitzung. Nützlich, wenn Sie eine einzelne dauerhafte Sitzung verwenden möchten, um Ereignisse im Zeitverlauf zu verarbeiten, anstatt für jedes Ereignis eine neue Sitzung zu starten. Beim Konfigurieren dieser Aktion müssen Sie die Zielsitzung auswählen.

Triage Devin (Überwachung)

Erstellt eine persistente Devin-Sitzung, die einen Slack-Channel überwacht. Vollständige Details zu diesem Aktionstyp finden Sie im Leitfaden zur [Auto-Triage](/de/product-guides/auto-triage).

E-Mail-Benachrichtigung

Sendet eine E-Mail-Benachrichtigung, wenn die Automatisierung ausgeführt wird. Wählen Sie aus, wann benachrichtigt werden soll: * **Immer** — bei jeder Ausführung * **Bei Fehlern** — nur wenn die Sitzung fehlschlägt oder ein Fehler auftritt * **Bei Erfolg** — nur wenn die Sitzung erfolgreich abgeschlossen wird

Begrenzungen und Schutzmechanismen

Automatisierungen verfügen über integrierte Schutzmechanismen, um einen ausufernden Verbrauch zu verhindern:

ACU-Limit

Legen Sie ein maximales ACU-Budget (Agent Compute Unit) pro Sitzung fest, die von dieser Automatisierung gestartet wird. Wenn Devin das Limit erreicht, wird die Sitzung beendet. So wird verhindert, dass ein einzelner Aufruf übermäßig viele Ressourcen verbraucht.

Aufruflimit

Legen Sie fest, wie oft die Automatisierung innerhalb eines Zeitfensters höchstens ausgelöst werden darf. Zum Beispiel verhindert „höchstens 10 Aufrufe pro Stunde“, dass ein besonders aktiver Slack-Channel oder eine Häufung von CI-Fehlschlägen zu Dutzenden von Sitzungen führt. Beide Felder sind optional — wenn sie geleert werden, wird die Automatisierung ohne dieses Limit ausgeführt. Neue Automatisierungen starten ohne ACU-Limit und mit einem **Ratenlimit** von 50 Ausführungen pro Stunde (150 pro Stunde bei Triage-Automatisierungen, die einen Slack-Channel überwachen); Vorlagen verwenden dieselben Standardwerte.

Warteschlange

Standardmäßig startet jedes passende Event sofort einen Run. Aktivieren Sie im Automatisierungs-Editor **Enable queueing**, um die Anzahl gleichzeitig laufender Runs zu begrenzen: * **Concurrent runs**: Die maximale Anzahl gleichzeitiger Runs dieser Automatisierung. Weitere Events warten in der Warteschlange. Ein Run zählt nicht mehr zum Limit, sobald seine Sitzung abgeschlossen ist und auf neue Anweisungen wartet. * **Queue depth**: Die maximale Anzahl von Events, die in der Warteschlange warten können. Events, die bei voller Warteschlange eintreffen, werden verworfen. Runs in der Warteschlange werden in der Aktivität der Automatisierung mit dem Status **Queued** angezeigt.

Netzwerkrichtlinie

Sie können eine Netzwerkrichtlinie aktivieren, um einzuschränken, auf welche externen Hosts die Sitzungen einer Automatisierung zugreifen können. Dies ist besonders wichtig für Automatisierungen, die nicht vertrauenswürdige Eingaben von Nutzern verarbeiten (z. B. Slack-Nachrichten, Webhook-Payloads). Sie können bestimmte Domains zur Allowlist hinzufügen, wenn Devin externe Dienste erreichen muss. Die Netzwerkrichtlinie einer Automatisierung schränkt den Zugriff ausschließlich ein: Sie wird mit dem [Sicherheitsprofil](/de/product-guides/security-profiles) für die Sitzungen der Automatisierung kombiniert, sodass nur der gemeinsame Zugriff erlaubt ist.

MCP-Integrationen

Es wird dringend empfohlen, MCP-Integrationen zu verbinden — sie verbessern die Qualität von Automatisierungen erheblich, weil Devin dadurch Zugriff auf Laufzeitdaten wie Logs, Metriken und Fehlerdetails erhält. Automatisierungen nutzen [MCP-Integrationen](/de/work-with-devin/mcp), um Devin Zugriff auf externe Tools zu geben. Beim Erstellen einer Automatisierung zeigt der Abschnitt **Connections**, welche MCP-Server empfohlen werden und welchen Verbindungsstatus sie haben. Zum Beispiel empfiehlt die Vorlage „Fix Sentry Errors Daily“ den Sentry MCP, damit Devin Sentry nach ungelösten Fehlern abfragen kann. Die Vorlage „Investigate Alerts Triggered“ empfiehlt den Datadog MCP, um Metriken und Traces abzurufen. Aktivieren Sie MCP-Server im Tab **Settings → Connections → MCPs** (oder installieren Sie deren Plugins aus dem Plugin-Marketplace), bevor Sie Automatisierungen erstellen, die sie benötigen.

Zugriff auf Slack-Tools

Standardmäßig können Automatisierungs-Sitzungen die am Trigger beteiligten Slack-Channels lesen und in sie schreiben. Im Abschnitt **Slack-Tools** des Automatisierungs-Editors können Sie Zugriff auf zusätzliche Slack-Channels gewähren. Das ist nützlich, wenn Devin aus mehreren Channels lesen muss, nicht nur aus dem Channel, der die Automatisierung ausgelöst hat.

Aktivität und Monitoring

Jede Automatisierung verfolgt ihren Ausführungsverlauf. Auf der Detailseite der Automatisierung zeigt der Tab **Aktivität** Folgendes an: * Neueste Ausführungen mit Zeitstempeln * Ob jede Ausführung erfolgreich war oder übersprungen wurde * Links zu den erstellten Devin-Sitzungen * Fehlermeldungen für fehlgeschlagene Ausführungen Die Automatisierungsliste zeigt für jede Automatisierung eine Sparkline, die einen visuellen Überblick über die Aktivität der letzten 30 Tage gibt.

Aktivieren und Deaktivieren

Sie können eine Automatisierung jederzeit über die Automatisierungsliste oder die Detailseite ein- oder ausschalten. Deaktivierte Automatisierungen verarbeiten keine Ereignisse mehr, behalten jedoch ihre Konfiguration bei. Wenn Sie eine Automatisierung erneut aktivieren, wird die Ereignisverarbeitung sofort fortgesetzt.

Vorlagen

Devin bietet eine Bibliothek vorgefertigter Automatisierungsvorlagen für gängige Workflows: | Vorlage | Kategorie | Funktion | | - | - | - | | Triage Bug Reports | Monitoring & Triage | Überwacht einen Slack-Channel auf Fehlerberichte – Devin triagiert jeden davon, untersucht die Root Cause und antwortet im Thread | | Triage Support Requests | Monitoring & Triage | Überwacht einen Support-Channel – Devin entwirft eine präzise Antwort im Thread und markiert alles, was eskaliert werden muss | | Triage Customer Bug Tickets | Monitoring & Triage | Wenn ein Kunde ein Issue in Pylon erstellt, reproduziert Devin den Fehler, untersucht die Codebase und meldet die Befunde an das Support-Team | | Investigate Support Escalations | Monitoring & Triage | Wenn der Support ein Pylon-Issue für das Engineering markiert, findet Devin die Root Cause, reproduziert sie, schlägt einen Fix vor und berichtet im internen Slack-Thread – markiert dabei den wahrscheinlichen Owner und legt ein Linear-Ticket an, falls Eskalationen dort geführt werden | | Investigate Alerts Triggered | Monitoring & Triage | Wenn ein Alert in deinem Slack-Alerts-Channel eingeht, nutzt Devin das Datadog MCP, um Metriken, Logs und Traces abzurufen, und postet anschließend eine Root-Cause-Analyse im Thread | | Fix Sentry Errors Daily | Monitoring & Triage | Ruft jeden Morgen die wichtigsten ungelösten Sentry-Fehler ab, untersucht jeden einzelnen und öffnet Fix-PRs | | Daily Error Report | Monitoring & Triage | Durchsucht jeden Morgen Datadog nach neuen und stark ansteigenden Fehlern in deinen Services und postet einen kompakten Bericht in Slack | | Recurring Capacity Planning | Monitoring & Triage | Prüft nach Zeitplan Trends bei Nutzung und Ressourcenauslastung, um den Kapazitätsbedarf zu prognostizieren und Services zu markieren, die sich ihren Grenzen nähern | | Fix CI Failures | CI/CD & Release | Behebt fehlschlagende CI-Prüfungen in Nicht-Devin-PRs automatisch – liest die Build-Logs, identifiziert die Root Cause, pusht einen Fix und verifiziert, dass er durchläuft | | /devin Issue Fix | CI/CD & Release | Wenn jemand `/devin` in einem GitHub-Issue kommentiert, untersucht Devin die Codebase und öffnet einen Fix-PR | | Weekly Dependency Update | CI/CD & Release | Sucht jeden Montag nach veralteten Paketen, prüft Changelogs auf Breaking Changes und öffnet Update-PRs, gruppiert nach Risikostufe | | Weekly Changelog | CI/CD & Release | Fasst jeden Freitag gemergte PRs in einem kategorisierten Changelog zusammen und öffnet einen PR, der CHANGELOG.md aktualisiert | | Stale PR Cleanup | CI/CD & Release | Wöchentlicher Scan nach PRs, die seit über einer Woche nicht aktualisiert wurden – prüft auf Merge-Konflikte und postet eine freundliche Erinnerung | | Scanner für Schwachstellen in Abhängigkeiten | Security | Täglicher Scan nach bekannten CVEs in deinen Abhängigkeiten, priorisiert nach Severity, inklusive Fix-PRs | | Secret Scanner | Security | Täglicher Scan nach geleakten Credentials, API keys und Tokens – ersetzt hartcodierte Secrets durch Referenzen auf Umgebungsvariablen und öffnet Fix-PRs | | Code Pattern Enforcer | Security | Wöchentlicher Vergleich deines Repos mit einem Golden-Reference-Repository, inklusive Angleichungs-PRs für Abweichungen | | OWASP Security Hardening | Security | Wöchentlicher Scan nach OWASP-Top-10-Schwachstellen – Injection-Lücken, XSS, fehlende Auth-Checks, unsichere Standardeinstellungen – inklusive Fix-PRs | | Cloudflare-Sicherheitsaudit | Security | Wöchentliche Prüfung der Cloudflare-Audit-Logs, um verdächtige Aktivitäten, Konfigurationsänderungen und potenzielle Sicherheitsprobleme zu markieren | | Weekly Status Digest | Project Management | Fasst jeden Montag die gemergten PRs der vergangenen Woche zu einem kompakten Status-Update zusammen und postet es in Notion | | Sprint Progress Report | Project Management | Eine tägliche Standup-Zusammenfassung aus Asana – ruft den Task-Status über alle Projekte hinweg ab und postet ein Fortschritts-Update in Slack | | Backlog Cleanup | Project Management | Ein wöchentlicher Durchlauf durch deinen Linear-Backlog – schließt inaktive und doppelte Issues, markiert nicht triagierte und ergänzt fehlende Labels, Prioritäten und Schätzungen | Um alle Vorlagen zu durchsuchen, öffne die Seite **Automatisierung** in der Devin-App und klicke auf **Create automation** > **Template** (oder gehe direkt zu `/automations/templates`). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.