Automatisierungen - Devin Docs

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 verwalten. Eine Videoanleitung mit vier Beispielen finden Sie im Tutorial zu Devin-Automatisierungen.

Kernkonzepte

Eine Automatisierung besteht aus einem Auslöser und Actions sowie optionalen Bedingungen und einem Preflight-Check:

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-Check	Ein optionaler LLM-Filter oder ein optionales Skript, der bzw. das ausgeführt wird, sobald ein Ereignis zutrifft, und zwar vor den Actions. Das Ereignis kann übersprungen oder durchgelassen werden; ein Skript kann es zudem in separate Arbeitseinträge aufteilen.
Action	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-Kanal ü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. Verwenden Sie für Warnmeldungen, Störungen und Fehlerberichte Devin Oncall.
E-Mail-Benachrichtigung	Sendet Ihnen eine E-Mail, wenn die Automatisierung ausgeführt wird — bei jedem Durchlauf, nur bei Fehlern oder nur bei erfolgreichen Durchläufen.

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
PagerDuty	Incident ausgelöst, bestätigt, behoben, aktualisiert	Incidents mit hoher Dringlichkeit untersuchen, sobald sie ausgelöst werden. Siehe die PagerDuty-Integration
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“

Gehen Sie in der Seitenleiste zu Automatisierungen
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)
Konfigurieren Sie den Auslöser, die Bedingungen und die Aktion
Klicken Sie auf Automatisierung erstellen

Aus einer Vorlage

Gehen Sie in der Seitenleiste zu Automatisierungen
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
Durchsuchen Sie die Vorlagengalerie — jede Vorlage ist eine vorkonfigurierte Automatisierung für einen gängigen Workflow
Klicken Sie auf eine Vorlage, um den Editor mit dem Auslöser, der Aktion und den vorgeschlagenen Limits der Vorlage vorab auszufüllen
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 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.

Erstellen Sie eine Automatisierung mit einem Webhook-Trigger
Kopieren Sie die in der Trigger-Konfiguration angezeigte Webhook-URL und das Secret
Konfigurieren Sie Ihr externes System (PagerDuty, Datadog, Sentry oder jedes benutzerdefinierte Tool) so, dass es HTTP-POST-Anfragen an diese URL sendet
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: <secret>-Header
Authorization: Bearer <secret>-Header
?secret=<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:

curl -X POST '<webhook-url>' \
  -H 'Content-Type: application/json' \
  -H 'X-Webhook-Secret: <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 optionaler Schritt, der zwischen einem passenden Auslöser und den Actions der Automatisierung ausgeführt wird. Eine Automatisierung kann eine von zwei Varianten verwenden:

Art	Funktion
LLM-Filter	Ein Entscheidungsmodell prüft jedes passende Ereignis und überspringt alle, die nicht zu Ihrer Beschreibung in natürlicher Sprache passen. Schnell und kostengünstig.
Skript	Ihr eigener Python-, Node- oder Bash-Code entscheidet, was passiert: einen externen Dienst aufrufen, den Zustand zwischen Durchläufen speichern oder für jedes neue Element eine Sitzung starten.

Klicken Sie zum Hinzufügen unterhalb des Auslöserbereichs auf Add a step before the agent runs und wählen Sie LLM-Filter oder Run a script.

Preflight-Skripte werden schrittweise eingeführt. Wird Run a script nicht angezeigt, sind Skripte für Ihre Organisation noch nicht aktiviert.

Die Schaltfläche Run now der Automatisierung umgeht den Preflight-Check und führt die konfigurierten Actions direkt aus.

LLM-Filter

Wählen Sie LLM-Filter aus und beschreiben Sie, welche Ereignisse berücksichtigt oder ausgeschlossen werden sollen. Zum Beispiel: „PRs zum Auth-Service“ oder „Slack-Nachrichten über das Abendessen“. Das schlanke Entscheidungsmodell liest das gesamte Ereignis. Nur passende Ereignisse lösen den Agent aus.

Ein Preflight-Skript konfigurieren und testen

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 Durchläufen eine kleine Menge an Zustandsdaten speichern und entscheiden, welche Arbeit an die konfigurierten Actions weitergegeben wird.

Erstellen Sie eine Automatisierung oder bearbeiten Sie eine bestehende, und konfigurieren Sie deren Auslöser und Bedingungen.
Klicken Sie unterhalb des Auslöser-Abschnitts auf Add a step before the agent runs und wählen Sie in der Karte Before the agent runs die Option Run a script aus.
Klicken Sie auf Edit script, wählen Sie im Laufzeit-Auswahlfeld Python, Node (JavaScript) oder Bash aus und passen Sie das Vorlagenskript an.
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.
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.
Wählen Sie im Skript-Editor unter Test against ein Ereignis aus und klicken Sie auf Durchlauf. 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.
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.

Testdurchlä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.

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:

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.

Skript-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 Durchlauf auslösen kann.
Obergrenze für Einträge pro Durchlauf: Standardmäßig werden pro Durchlauf 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 Skriptdurchlauf 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 Durchlauf fehlschlägt, wird freigegeben, sodass ein späterer Skriptdurchlauf ihn erneut ausgeben kann.
Persistenter Zustand: Live-Skriptdurchlä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. 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 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.

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 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, 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).

​Kernkonzepte

​Aktionstypen

​Trigger-Quellen

​Automatisierung erstellen

​Auf der Seite „Automatisierungen“

​Aus einer Vorlage

​Mit natürlicher Sprache

​Trigger konfigurieren

​Slack-Trigger

​GitHub-Trigger

​GitLab-Trigger

​Linear-Trigger

​Jira-Trigger

​Zeitplan-Trigger

​Webhook-Trigger

​Webhook-Secret

​Preflight-Checks

​LLM-Filter

​Ein Preflight-Skript konfigurieren und testen

​Ein- und Ausgabe des Skripts

​Skript-Einträge, Zustand und Limits

​Actions konfigurieren

​Sitzung starten

​Nachricht an eine Sitzung

​Triage Devin (Überwachung)

​E-Mail-Benachrichtigung

​Begrenzungen und Schutzmechanismen

​ACU-Limit

​Aufruflimit

​Warteschlange

​Netzwerkrichtlinie

​MCP-Integrationen

​Zugriff auf Slack-Tools

​Aktivität und Monitoring

​Aktivieren und Deaktivieren

​Vorlagen

Kernkonzepte

Aktionstypen

Trigger-Quellen

Automatisierung erstellen

Auf der Seite „Automatisierungen“

Aus einer Vorlage

Mit natürlicher Sprache

Trigger konfigurieren

Slack-Trigger

GitHub-Trigger

GitLab-Trigger

Linear-Trigger

Jira-Trigger

Zeitplan-Trigger

Webhook-Trigger

Webhook-Secret

Preflight-Checks

LLM-Filter

Ein Preflight-Skript konfigurieren und testen

Ein- und Ausgabe des Skripts

Skript-Einträge, Zustand und Limits

Actions konfigurieren

Sitzung starten

Nachricht an eine Sitzung

Triage Devin (Überwachung)

E-Mail-Benachrichtigung

Begrenzungen und Schutzmechanismen

ACU-Limit

Aufruflimit

Warteschlange

Netzwerkrichtlinie

MCP-Integrationen

Zugriff auf Slack-Tools

Aktivität und Monitoring

Aktivieren und Deaktivieren

Vorlagen