Watch devices during an incident with a Claude Code /loop and rConfig MCP

Watch devices during an incident with a Claude Code /loop and rConfig MCP

During an incident or a long change window, someone ends up refreshing rConfig to see whether the core switches have changed again. A Claude Code loop does that for you: it checks a short watch list every few minutes, remembers what it saw last time because it runs in the same session, and only speaks up when a device has a new config version or its compliance result flips.

Best for: active incidents, multi-hour change windows, watching a device after a risky change, handover between shifts. Tools: rConfig, Claude Code in an open session. rConfig tools used: get_devices, get_config_history, get_config_diff, get_compliance_status.

Uplink guideAlert to root cause: Zabbix, PagerDuty and Grafana MCP with rConfigAn AI agent reads a Zabbix, PagerDuty or Grafana alert over MCP, checks rConfig for config changes on the device, and explains if a change fits the symptom.Read the guide

How it flows

sequenceDiagram
    participant E as Engineer
    participant C as Claude Code
    participant R as rConfig MCP
    E->>C: Set the watch list and baseline
    C->>R: get_config_history (each device)
    C->>R: get_compliance_status (each device)
    C-->>E: Baseline: version IDs and compliance
    loop every 10 minutes
        C->>R: get_config_history (each device)
        C->>R: get_compliance_status (each device)
        alt something changed
            C->>R: get_config_diff (last seen → new)
            C-->>E: What changed, on which device, when
        else nothing changed
            C-->>E: One line: "no change"
        end
    end

Start the watch

First, give the session the context in one ordinary prompt, so the loop has a baseline to compare against:

We’re in incident INC-48213, a WAN outage at the Dublin site. Using rConfig, record the latest running-config version and compliance result for dub-wan-01, dub-wan-02, dub-core-01 and dub-core-02. Show them as a table. This is the baseline for the next few hours.

Then start the loop:

/loop 10m Using rConfig, check the four devices in the baseline. For each,
compare the latest running-config version with the last one you reported and
check compliance. If nothing changed on any device, reply with one line:
"HH:MM no change". If a device has a new version, diff it against the last one
you reported and give device, backup time, and the changed lines. If a
compliance result changed, say which policy and which rules. Then update your
baseline to what you just saw. If rConfig doesn't answer, say so first.

Claude Code runs the prompt every ten minutes while the session is open. Ask it to cancel the loop when the incident closes.

An illustrative iteration:

02:40 dub-core-02 has a new running-config (v18904, backed up 02:31).
  interface Port-channel10
  - switchport trunk allowed vlan 10,20,30
  + switchport trunk allowed vlan 10,20,30,40
Compliance unchanged: all four devices pass "Core switch baseline".
Other devices: no change.

Choosing the interval

Match the interval to rConfig’s backup schedule for those devices. The loop sees a change only after rConfig has backed it up. For the duration of the incident, a short backup schedule on the watched devices matters more than a short loop.

Limits to know

• The session must stay open. Closing Claude Code, or the machine sleeping, ends the loop. For checks that must survive a laptop lid, use a scheduled job instead.
• Loops expire after seven days, and runs missed while the session was busy aren’t caught up.
• Every iteration is model usage. Four devices every ten minutes for eight hours is 48 iterations. “No change” replies are short, but each one still reads history for every device.
• The context grows. In a very long session, earlier detail is summarised. The prompt keeps a running baseline so the comparison doesn’t depend on the full history.

Guardrails

• The loop only reads. If it suggests a rollback, that goes through your incident process.
• Use your own token, so the loop sees what you can see, or a token scoped to the incident’s devices.
• Keep the watch list short. A loop is for a handful of devices you care about right now, not the estate.

Variations

• Change window watch. Start the loop when the window opens with the approved change list in the first prompt, and ask it to flag any change on a device that isn’t on the list.
• Shift handover. Before you hand over, ask for a timeline of everything the loop reported, with backup times. Paste it into the incident ticket.
• Compliance-only watch. After a remediation push, loop on get_compliance_status for the affected group until every device passes, then stop.

Related reference

• Connect an AI agent over MCP
• Scheduled Tasks: backup schedules for the watched devices
• Network configuration diff analysis
• Policy Compliance Results
• Claude Code