Scheduled Agents mit Claude Code Routines

Routines sind seit April 2026 Teil von Claude Code. Du gibst einem Agent einen Cron-Schedule und ein Prompt, und er fährt selbständig zur gewünschten Zeit los, ohne dass Du in der Session sein musst. Das ersetzt für viele Operator den eigenen crontab mit Shell-Skripten oder den n8n-Workflow.

Der Punkt: Routines laufen auf Anthropic-Infrastruktur, nicht auf Deinem Rechner. Heißt: sie laufen während Du schläfst, sie überleben Reboots, und sie sehen Deine Repos via GitHub-Verbindung plus die Connectors die Du bei der Erstellung ausgewählt hast.

Stand April 2026, getestet mit Claude Code v2.1.118 plus, offizielle Doku. Verfügbar auf Pro, Max, Team, Enterprise mit aktiviertem Claude Code on the web.

Was Du am Ende hast

Drei laufende Routines die Du nach diesem Playbook gebaut hast:

1. Ein täglicher Morgen-Brief um 06:00 der Sprint, MCP-Health und Inbox-Status zusammenfasst und Dir per Slack oder E-Mail schickt.
2. Ein Inbox-Triage am Mittag der neue Mails labelt und unwichtige automatisch archiviert.
3. Ein Deploy-Watcher der nach jedem Push auf main 15 Minuten wartet und dann checkt ob die Production-Container alle healthy sind.

Alle drei nutzen Connectors die Du beim Routine-Setup auswählst. Kein neuer Code, nur Konfiguration.

Schritt 1: Routine anlegen

In Claude Code tippst Du:

/schedule

Claude öffnet einen Dialog der Dich nach Name, Schedule (Cron oder natürliche Sprache), Prompt, Repositories und Connectors fragt. Du kannst die Beschreibung auch direkt mitgeben:

/schedule daily 06:00, run the morning-brief skill and post to Slack

Für einen Einmal-Lauf in der Zukunft:

/schedule in 2 weeks, open a cleanup PR for the feature flag we just shipped

Die Routine wird in Deinem claude.ai-Konto gespeichert, nicht in einer lokalen Datei. Sie ist account-scoped, nicht projekt-scoped, also taucht sie in jeder Deiner Sessions auf und im Web-UI unter claude.ai/code/routines.

Über die CLI legst Du nur Schedule-Trigger an. API-Trigger und GitHub-Event-Trigger fügst Du danach im Web-UI hinzu.

Vier Subcommands die Dir den Alltag erleichtern:

/schedule list      # alle Deine Routines anzeigen
/schedule update    # eine Routine editieren
/schedule run       # eine Routine sofort feuern, ohne auf den naechsten Slot zu warten
/schedule           # neue Routine konversationell erstellen

Schritt 2: Morgen-Brief

Routine morning-brief, Schedule 0 6 * * 1-5 (Mo-Fr 06:00):

Du bist der Morgen-Brief-Bot. Aufgabe:

1. Lies den aktuellen Sprint-Stand aus dem Memory-Connector
2. Prueft die MCP-Fleet-Health
3. Liest den Inbox-Status aus dem Mail-Connector
4. Prueft heutige Follow-Ups aus dem CRM-Connector

Schreib ein 200-Wort Briefing in Reddit-Tonalitaet. Was muss heute
passieren, was bleibt liegen, was sind die zwei wichtigsten
Entscheidungen die ich anstoßen muss.

Schick das Briefing per Slack an mich (Slack-Connector, Channel
"morning-brief").

Bei der Erstellung wählst Du im Connector-Picker den Slack-Connector und die Memory- plus CRM-Connectors aus. Repositories brauchst Du keine, da der Bot nicht im Code arbeitet.

Bedenk den Mindest-Cron-Abstand: 1 Stunde. Häufiger geht über /schedule nicht.

Schritt 3: Inbox-Triage

Routine inbox-triage, Schedule 0 12 * * * (täglich 12:00):

Du bist der Inbox-Triage-Bot. Aufgabe:

1. Lies neue Mails der letzten 6 Stunden ueber den Mail-Connector
2. Pro Mail: ist das ein Lead, eine Lieferanten-Mail, ein Newsletter,
   oder ein Bot-Bounce?
3. Lead → Label "lead" + automatische Antwort mit Acknowledgement
4. Newsletter → archive
5. Bot-Bounce → archive
6. Lieferanten-Mail → Label "vendor", liegen lassen für menschlichen Review
7. Schick eine Zusammenfassung per Slack: "X Mails getriggert,
   Y archiviert, Z Leads"

Wichtig: lass den Bot nicht von sich aus wichtige Mails archivieren. Wenn er unsicher ist, soll er die Mail mit Label "review-needed" liegen lassen.

Schritt 4: Deploy-Watcher

Den Deploy-Watcher baust Du als Routine mit API-Trigger statt Schedule. Du erstellst die Routine erst über /schedule (nur Prompt + Repos + Connectors), dann gehst Du auf claude.ai/code/routines, öffnest die Routine, und fügst über "Add another trigger → API" einen API-Trigger hinzu. Du bekommst eine HTTP-URL und einen Bearer-Token zurück.

Prompt der Routine:

Du bist der Deploy-Watcher. Du wirst nach einem Production-Deploy
getriggert.

Aufgabe:
1. SSH-Connector zu Prod, lies docker ps Status
2. Curl die /health Route der App
3. Wenn alle gruen: kurze Slack-Bestaetigung "Deploy healthy"
4. Wenn ein Container unhealthy oder /health failed:
   - Logs der letzten 5 Minuten ziehen
   - Slack-Alert mit Container-Name, Status, Logs

Im Deploy-Skript am Ende triggerst Du die Routine per HTTP POST:

curl -X POST https://api.anthropic.com/v1/claude_code/routines/trig_01ABC.../fire \
  -H "Authorization: Bearer sk-ant-oat01-xxxxx" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Production deploy of commit abc123 just finished, please verify"}'

Die Routine startet eine neue Session und Du kriegst die Session-ID plus URL zurück. Den Token speicherst Du sicher, er wird einmal angezeigt und kann nicht erneut abgerufen werden. Falls Du ihn rotieren willst: gleicher Modal im Web-UI, "Regenerate" oder "Revoke".

Statt 15 Minuten zu warten ist der saubere Weg: das Deploy-Skript triggert die Routine nach dem Deploy direkt. Wenn Du wirklich warten musst, bau einen API-Trigger der erst nach 15 Minuten von Deinem Deploy-Skript gefeuert wird (z.B. via at now + 15 minutes oder einer separaten cron-Zeile).

Limit: Was Routines NICHT können

• Kein direkter Zugriff auf Deinen lokalen Filesystem-State. Routines laufen in Anthropic-Cloud-Sessions, sie sehen Deine Repos via Clone (auf den default branch zu Beginn jedes Runs) plus die Connectors die Du auswählst.
• Mindest-Cron-Abstand 1 Stunde. Häufiger geht nicht über /schedule. Wenn Du minutenweise Triggern willst, ist das ein Job für lokales crontab oder ein systemd Timer.
• Daily Cap pro Account. Jedes Konto hat ein tägliches Routine-Run-Limit. One-off Runs (z.B. /schedule in 2 weeks, ...) zählen nicht gegen das Cap, sie ziehen aus Deinem normalen Subscription-Usage.
• Routines haben Schreibrechte standardmäßig nur auf claude/-prefixed Branches. Wenn Du willst dass die Routine auf main oder andere existing Branches pushen darf, aktivierst Du im Routine-Editor "Allow unrestricted branch pushes" pro Repo.

Logs und Debugging

Run-Logs liegen in der Web-UI bei claude.ai/code/routines. Klick auf eine Routine, dann auf einen einzelnen Run. Du siehst eine vollständige Session, kannst nachvollziehen was Claude getan hat, Änderungen reviewen oder eine Pull-Request erstellen.

Wenn ein Run silent failed, sind die häufigsten Ursachen:

• Connector wurde nach dem Routine-Setup entfernt und das Prompt braucht ihn
• Tool-Name im Prompt veraltet (z.B. weil Du den MCP-Server geupdated hast)
• Daily Cap erreicht, Status sichtbar auf claude.ai/settings/usage

Was sich anders anfühlt als Cron

Bei Cron schreibst Du ein Bash-Skript das ein anderes Tool aufruft. Bei Routines ist die Routine selbst der Agent: sie hat einen Prompt, sie kann nachdenken, sie kann basierend auf dem was sie findet entscheiden was zu tun ist.

Beispiel: Dein normaler Cron für "Health-Check" ist eine if curl -f / failed → send mail. Eine Routine kann stattdessen "wenn Health failed, schau in den Logs warum, klassifiziere ob das ein bekanntes Pattern ist, und entscheide ob alarmieren oder erstmal Restart versuchen". Mehr Intelligenz, weniger Brittleness.

Naechste Schritte

Wenn Du das Setup aus diesem Playbook hast und drei Routines laufen, schau in die Crews die wir in Level 5 bauen, das ist der Schritt von "ein Agent erledigt eine Aufgabe" zu "mehrere Agents arbeiten zusammen".

Plus: Routines gibt's auf Max Plan flat-rate, auf Pro nur in begrenztem Umfang. Wenn Du viele Routines parallel laufen lassen willst, ist Max Plan günstiger.

Quelle

Die hier beschriebenen Mechaniken kommen aus der offiziellen Anthropic-Doku unter code.claude.com/docs/en/routines. Wenn ein Flag, ein Pfad oder ein Subkommando dort nicht steht, existiert es nicht.