Damira Cloud · Pilot program
NOC agents that work the alert queue. They never touch production.
Damira watches your alerts in the background, reads the network to find the cause, and hands your team the fix as a ServiceNow change request, with pre-checks and rollback. Your team approves and runs it. Damira confirms it worked.
- ✓Read-only access to your infrastructure
- ✓Every change goes through your change process
- ✓Your ServiceNow ticket is the record
EDGE-R1 · BGP peer 10.20.0.2 down
7 alerts grouped · 2 sites · first seen 02:14
Probable cause · high confidence
MTU on Gi0/0/1 changed from 1500 to 9000 in Tuesday's WAN change. The peer is still at 1500, so the session resets whenever full-size updates are sent.
No button changes a device. The worst a mis-click can do is open a ticket.
The boundary
It reads your network and writes the paperwork. That's all.
- Monitoring alerts and metrics
- Catalyst Center, Meraki, Nexus Dashboard
- Device show output
- Your source of truth (NetBox)
Read-only accounts you create
- Triage cards in Teams, Webex or Slack
- ServiceNow incidents
- Change requests, left in draft
- Verification notes on the ticket
Paperwork only
- Config pushes or template deploys
- Acknowledging or clearing alerts
- Moving a change past draft
- Anything your change board hasn't approved
No code path exists for it
Read-only is enforced three ways: the accounts you create can't write, the integrations run in read-only mode, and Damira drops any write action before it can be called.
How an incident runs · example
From alert to verified fix, without Damira touching a device
- 0salertSolarWinds: BGP peer 10.20.0.2 down on EDGE-R1
- 4sdamiraGrouped 7 related alerts into 1 incident
- 19sdamiraRead neighbor state, interface counters, recent changes
- 41sdamiraProbable cause: MTU mismatch after Tuesday's WAN change
- 43sdamiraTriage card posted to #noc with the suggested fix
- 58sengineerDraft change request → CHG0041187 created in ServiceNow
- —your cabApproves and runs the change in your window
- +5mdamiraRe-read BGP and interface state: PASS, evidence on the ticket
What it produces
The work your NOC writes by hand today
| Output | When | Where it lands |
|---|---|---|
| Triage card | Per incident | Teams · Webex · Slack |
| Draft change request | When a fix is needed | ServiceNow |
| Shift turnover | Every shift change | Chat + docx |
| Weekly status report | Weekly | Chat + ServiceNow |
| Account / QBR review | Quarterly | pptx |
Fits what you run
Your tools, your change process, hosted or on your side
- Monitoring
- SolarWinds · Prometheus · Grafana · LibreNMS
- Controllers
- Catalyst Center · Meraki · Nexus Dashboard
- Ticketing
- ServiceNow
- Chat
- Microsoft Teams · Webex · Slack
Hosted pilot
- Alerts arrive by email or webhook
- No infrastructure credentials leave your network
- Triage and suggested fixes in your chat
In your environment
- Runs next to your tools, outbound connections only
- Read-only accounts stay on your side
- Full ServiceNow tickets and change requests
Questions
What operators ask first
- Can it fix things on its own?
- No. It reads your infrastructure and writes paperwork. Your team, or your own automation, runs every change through your change process.
- What access does it need?
- Read-only accounts for monitoring and controllers, and a ServiceNow user that can create incidents and draft changes. We give you the exact role for each product and a check that proves none of them can write.
- Do we replace our monitoring?
- No. It works from the alerts and tools you already run.
- What does a pilot start with?
- Last week. Send an export of your alerts and tickets, and we send back a shift turnover, a noise analysis and draft change requests for the real problems in it.