Monitoring & Alerts

Damira reads what you paste. It doesn't connect to your monitoring stack. Copy what your tools are showing — an alert, a PromQL result, a Grafana panel value, a Loki or syslog excerpt, an incident ticket — into your Cursor or Claude Code session and ask what's going on.

Damira doesn't need credentials to your monitoring systems and can't reach them, so nothing leaves your network unless you paste it.

What Damira does with it

1. Correlates the evidence. It lines up timestamps, devices, and interfaces across your alerts, metrics, and logs, and separates the cause from the symptoms.
2. Matches it to vendor knowledge. It links log messages and counters to the platform's documented behavior, known bugs for your release, and relevant CVEs.
3. Runs a structured diagnosis. You get a ranked list of likely causes, each with the exact show commands that confirm or rule it out. Damira recommends the commands and you run them.
4. Drafts the write-up. Once you know the cause, your AI can write the incident report or the ServiceNow-ready fields (category, priority, affected CI, impact, and resolution notes) for you to paste into the ticket.

What to paste

Include the platform and software version if you know them. Damira's advice is version-specific.

Example prompts

A firing alert

This alert just fired. What's the most likely cause and what do I check first?

ALERT BGPPeerDown
  labels: instance=wan-rtr-01:9100, peer=203.0.113.9, peer_asn=64512, severity=critical
  started: 2026-09-24T14:02:11Z
  summary: BGP session to 203.0.113.9 (AS64512) left Established

Platform: ASR 1001-X, IOS-XE 17.9.4a. Our side of the peering is Gi0/0/0.

A metric snapshot

Interface errors on our core uplink started climbing at 09:40. Here's the Prometheus result:

rate(ifInErrors{instance="core-sw-02",ifName="Ethernet1/49"}[5m])
  09:35  0
  09:40  4.2
  09:45  18.7
  09:50  22.1

ifOperStatus is still up. The link is a 100G-SR4 to dist-sw-07.
Platform: Nexus 93180YC-FX, NX-OS 10.3(4a). What's likely going on?

Logs around the event

Users on the 3rd floor lost connectivity for about 2 minutes. Here's syslog from the access switch:

Sep 24 11:17:03 acc-3f-01 %SPANTREE-2-ROOT_CHANGE: Root Changed for vlan 30: New Root Port is GigabitEthernet1/0/48
Sep 24 11:17:03 acc-3f-01 %SPANTREE-2-ROOT_CHANGE: Root Changed for vlan 40: New Root Port is GigabitEthernet1/0/48
Sep 24 11:17:04 acc-3f-01 %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/47, changed state to down
Sep 24 11:19:10 acc-3f-01 %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/47, changed state to up

Catalyst 9300, IOS-XE 17.12.3. Gi1/0/47 and Gi1/0/48 are the two uplinks to the distribution pair.
Why did the root port move, and why did users drop?

An incident ticket, then the write-up

INC0048213. Remote site Denver reports that calls drop after exactly 15 minutes.
Started Monday. Affects every phone at the site. Headquarters is fine.
Denver connects over DMVPN through an ISR 4331 on IOS-XE 17.6.5.

Diagnose this. When we've found the cause, draft the ServiceNow resolution notes
and the fields: category, subcategory, priority, affected CI.

For the last step, your AI writes the incident report or ticket fields from the diagnosis. Damira supplies the facts and your AI assembles the document. See Documents.

Tips

• Paste the raw output. Unedited alert labels and log lines carry the timestamps and identifiers Damira correlates on.
• Give it a time window. Logs from a few minutes before the first alert usually hold the cause. The alert itself is often a symptom.
• Keep the session going. Paste the output of the commands Damira suggests back into the same session. Each round narrows the diagnosis.

Related

• Troubleshooting: how the structured diagnosis works
• Documents: incident reports, MOPs, and change controls
• Security: what happens to what you paste