Incident Response Information System

Know about the outage before the phone rings.

Most monitoring tools check on your switches every minute or five, and hand you a pile of alarms when one goes dark. IRIS checks every ten seconds, works out which one alarm actually matters, and puts you on the affected switches from the same screen.

Execute. Monitor. Control.   $1 per host per year, flat.

Network Dashboard Live
Streaming
Reachable
4,812
Unreachable
23
Open incidents
7
Active incidents ranked by impact
Critical ACME-HQ-MDF-01 frame down · 12 IDFs · 340 hosts 4m 12s
Major ACME-EAST-IDF-11 Gi1/0/41 flapping · UPS link 27m
Env ACME-WEST-IDF-03 inlet 41°C · fan 2 degraded 1h 08m
Core bandwidth · 10s 2.41 Gbps in · 612 Mbps out
Where IRIS stands apart
Time to notice a dead closet Typical NMS: 1 to 5 minutes 10 seconds
What you get when an MDF fails Typical NMS: one alarm per device 1 incident, root named
Fixing 250 switches Typical NMS: 250 SSH windows 1 tab, 1 command
What it costs Typical NMS: per device, per module, quote required $1 per host, all in
Why teams switch

Three questions every outage asks. Most tools answer none of them.

Why did nobody know? Which alarm is the real one? Who is going to fix it, and how fast? A monitor, a ticket queue and a terminal that never talk to each other leave you to answer all three by hand. IRIS was built so the answers are already on the screen.

Monitor

You find out in ten seconds, not whenever the next poll lands.

Most tools check reachability every one to five minutes and collect bandwidth every five. That is long enough for a closet to drop, reboot and come back without anyone seeing it, and long enough to average a thirty-second saturation event into a flat line. IRIS pings every host every ten seconds and reads bandwidth at the same rate on the ports that matter, so a flap is a flap and a spike is a spike.

  • See the spike, not the average. Zoom into any port and the chart refines to the raw ten-second readings, so the backup job that saturates a WAN link for forty seconds is visible instead of smoothed away.
  • Catch the flap the slow poll misses. Core gear gets more probes than an access switch, automatically, so a wobbling uplink is flagged while a healthy lab switch stays quiet.
  • Know the closet is cooking before the switch reboots. Temperature, fans, power supplies, PoE budget and UPS battery age are watched with the same attention as reachability, because most outages start as an environment problem.
  • A bad cable shows up before a ticket does. Errors, discards and link flaps per port turn the vague "the wifi is slow in the east wing" into a specific patch cable on a specific switch.
Site health · last 7 days 14 sites
ACME-HQ
31 inc
ACME-EAST
12 inc
ACME-WEST
5 inc
ACME-LAB
1 inc

ACME-HQ accounts for 63% of site incidents this week.

PoE drawn · EAST IDF-11 412 W of 740 W budget
Inlet temp · WEST IDF-03 41 °C warn ≥ 40 °C
UPS batteries 38 / 41 3 past replace date
Ping

Packet loss across the whole fleet, sorted by how much it hurts.

In most tools ping is a green or red dot. IRIS probes every host every ten seconds and keeps the loss and jitter of every window, then lays the fleet out as a heat table: the deeper the red, the worse the loss; amber for jitter; green for hosts that are simply fine. One glance says which site is in trouble and whether it is one closet or all of them.

  • Loss now, and loss over time. A host at 3 % loss for most of the last hour is a different problem from one at 33 % for two windows. Both columns are there, so you can tell them apart.
  • Jitter without loss is its own row. Phones and video fail on jitter long before packets drop. Those hosts surface in amber even when their loss is zero.
  • Patterns jump out. Six closets at one site all losing packets, with the MDF among them, is an uplink problem. The table shows you that before you open a single host.
  • Any window, same thresholds. Flip between the last hour, six hours or a day and the table re-ranks. Every row links to that host's full ping history.
iris> 10.0.0.0/16 IPv4 > 21 hosts 1h 6h 24h
Affected hosts 11 of 21 in window
Worst loss 33.3% ACME-HQ-CORE-01
Loss windows 18.4% 133 / 723 buckets
Worst jitter 163.2ms 5 jitter buckets
Failed pings 1,203 of 14,398 sent
Packet Loss and Jitter 21
Showing 13 of 21 hosts. Thresholds apply to the selected window.
Ip addressHostSiteFrameLossLoss windowsJitterJitter windowsLatencySuccessProbesLostLast
10.0.7.250ACME-HQ-CORE-01Packet lossACME-HQMDF33.3%7.4% 2/270.8ms0.0% 0/271.3ms100.0%812720s
10.0.45.12ACME-EAST-IDF-12Packet lossACME-EASTIDF-1221.2%44.1% 26/596.6ms0.0% 0/599.9ms100.0%1,2572661m
10.0.45.11ACME-EAST-IDF-11Packet lossACME-EASTIDF-1115.2%46.7% 28/6016.9ms0.0% 0/6010.9ms100.0%1,26519220s
10.0.45.13ACME-EAST-IDF-13Loss + jitterACME-EASTIDF-1314.3%30.0% 18/6051.8ms3.3% 2/6017.1ms100.0%1,32018920s
10.0.45.15ACME-EAST-IDF-15Packet lossACME-EASTIDF-1512.1%23.3% 14/6024.5ms0.0% 0/6013.5ms100.0%1,21814720s
10.0.45.254ACME-EAST-MDF-01Packet lossACME-EASTMDF11.1%45.0% 27/605.9ms0.0% 0/608.5ms100.0%1,99822220s
10.0.54.11ACME-WEST-IDF-11Packet lossACME-WESTIDF-115.6%1.7% 1/6022.2ms0.0% 0/606.2ms100.0%1,0756020s
10.0.68.254ACME-LAB-MDF-01Packet lossACME-LABMDF2.9%1.7% 1/606.2ms0.0% 0/603.1ms100.0%1,7785220s
10.0.38.249ACME-HQ-IDF-09JitterACME-HQIDF-090.0%0.0% 0/27163.2ms3.7% 1/27111.2ms100.0%81020s
10.0.1.250ACME-HQ-IDF-03JitterACME-HQIDF-030.0%0.0% 0/2780.0ms7.4% 2/274.2ms100.0%81020s
10.0.54.15ACME-WEST-IDF-15JitterACME-WESTIDF-150.0%0.0% 0/6073.3ms3.3% 2/607.9ms100.0%1,075020s
10.0.62.250ACME-LAB-IDF-02HealthyACME-LABIDF-020.0%0.0% 0/600.4ms0.0% 0/600.9ms100.0%1,080020s
10.0.12.250ACME-HQ-IDF-12HealthyACME-HQIDF-120.0%0.0% 0/600.3ms0.0% 0/600.6ms100.0%1,080020s
Read it Five closets at ACME-EAST are losing packets and so is the MDF that feeds them. That is one uplink to fix, not five tickets.
Bandwidth

A bandwidth chart you can interrogate, not just look at.

Most tools give you a five-minute average and a date picker. IRIS gives you a live chart that scrolls with the clock, zooms under your cursor and fetches finer data as you go, all the way down to the raw ten-second readings. Drag across a spike and you land on a page that already knows which incidents, which conversations and which hosts were involved in that exact window.

  • Zoom, and it refines. Scroll on the chart and the time under your cursor stays put while the data around it reloads at a finer grain. No reload, no lost place.
  • Drag a spike, get the whole story. Any selection opens a shareable investigation page: the timeline, the incidents open at the time, the top talkers from packet capture, and the hosts that dropped pings.
  • Latency beside throughput. Round trip, jitter and reachability for the core path sit next to the traffic that caused them, so "slow" and "busy" stop being separate tickets.
  • Fast at a year of history. Ten-second readings for a week, minutes for a fortnight, hours for a quarter, days for a year. Every chart picks the right tier so it opens in a blink.
ACME-HQ · WAN circuit Live 10 s
1h 6h 24h 7d scale: symlog · effects: subtle
Current total 3.02 Gbps
In 2.41 Gbps
Out 612 Mbps
ISP usage 61 %
Headroom 1.98 Gbps
4G2G1G0 circuit 5 Gbps 14:20 to 14:52 · release to investigate 12:0013:3014:3616:00now 7d · click to recenter · drag to pick a window
Window investigation · 14:20 to 14:52 · ACME-HQ WAN shareable link · cadence: native 10 s
Incidents in window
MajorACME-HQ-IDF-07 uplink flap 14:31
ClosedACME-HQ-IDF-03 PoE fault 14:40
Top talkers · PCAP
10.0.12.40 → backup.acme1.84 GB
10.0.31.7 → cdn edge412 MB
Ping · loss and jitter
ACME-HQ-IDF-074.2 % loss · 18 ms jitter
ACME-HQ-CORE0 % · 0.6 ms
Fleet PoE · 4 sites · 31 switches · 1,488 ports 9.4 kW of 21.2 kW · 44 %
38%3.1 / 8.1 kW ACME-HQ
76%4.2 / 5.5 kW ACME-EAST
52%1.9 / 3.7 kW ACME-WEST
6%0.2 / 3.9 kW ACME-LAB
Drift ACME-EAST-IDF-11 Gi1/0/17 is drawing 18 % less than its 7-day baseline. A camera or phone is probably failing.
ACME-EAST-IDF-11 · breaker panel · 48 ports 412 W of 740 W
15.4
6.2
6.1
srch
12.8
6.0
25.1
srch
6.3
15.0
6.1
srch
6.2
6.0
13.1
6.4
5.1
6.2
srch
15.3
fault
6.1
12.9
srch
delivering searching drifting fault showing 24 of 48
Planner 12 more cameras at 15.4 W each: fits comfortably, 143 W headroom left on this switch.
Power over Ethernet

Every watt in every closet, from the whole fleet down to one port.

"Can this closet take twelve more cameras?" is usually answered by walking to the switch. Most monitors do not track PoE at all; the ones that do show a per-switch total. IRIS reads the real budget from each switch, shows the fleet as a wall of dials, and drills from site to frame to a breaker-panel view of every port with its live draw.

  • Plan before you buy. Type a device count and wattage and get a verdict per switch: fits comfortably, stage the rollout, or exceeds budget.
  • Drift catches failing devices. Every port's draw is compared to its own seven-day baseline. A phone pulling 18 % less than usual is flagged before it goes silent.
  • Power has a history too. Per-port watts are recorded on every poll, so a port's power chart sits beside its bandwidth chart on the same page.
  • Faults roll up. A port in fault state counts at the frame, the site and the fleet, so one bad injector never hides in a table.
UPS and batteries

Every UPS, every battery, without driving to a single site.

Finding out the state of a UPS usually means a truck roll and a web console per device. IRIS scans every UPS on the network from one place and keeps charge, load, voltage, alarms and battery age for each one, so you know which closet is on battery and which battery is due before anyone leaves the office. Ageing against a two-year warning and a three-year expiry turns replacements into a planned trip with a parts list, not a surprise.

  • Discovery, not data entry. Point the scanner at a range with your stored credentials and it finds every UPS, model, serial, charge and battery date, then rescans hourly.
  • On battery means something. Each UPS is mapped to the closet it protects, so "on battery" becomes "this frame has about forty minutes left" on the incident.
  • Storms show up as a pattern. Two or more sites reporting UPS events in the same half hour is flagged as a rolling outage, not four unrelated tickets.
  • One trip, one list, no console hopping. Filter to the expired set and you have the visit planned. After the swap, enter the install date once for all of them and IRIS records it on each UPS, so the next check starts from the truth.
UPS batteries
31 healthy 6 warning 4 expired
DeviceProtectsChargeAgeStatus
ACME-HQ-UPS-03 · SMT1500 HQ-IDF-03 100 % 3.4 y Expired
ACME-EAST-UPS-01 · SMX3000 EAST-MDF-01 47 % 3.1 y Expired
ACME-WEST-UPS-02 · SMT750 WEST-IDF-02 98 % 2.3 y Warning
ACME-HQ-UPS-01 · SRT5K HQ-MDF-01 100 % 0.4 y Healthy
ACME-LAB-UPS-01 · SMT1000 LAB-IDF-01 31 % 1.2 y On battery
2 selected · filter: expired Replace batteries on 2 devices
Replacement batch Running
Install date 2026-09-09 · 6 devices
ACME-HQ-UPS-03written, verified
ACME-HQ-UPS-04written, verified
ACME-EAST-UPS-01written, verified
ACME-EAST-UPS-02written, verified
ACME-WEST-UPS-01written, verified
ACME-WEST-UPS-03retrying with 2nd credential
Tomorrow 08:00 Battery digest to 3 subscribers: 4 expired, 6 in warning, 1 low charge. Repeats weekly for age, daily for charge, until fixed.
Packet capture

The capture already happened. You just have to look.

Packet capture usually means a laptop, a span port and someone remembering to press start after the problem is over. IRIS captures continuously at the points you choose, turns the stream into flows and conversations you can search, and keeps the raw segments so you can open any single packet in full. When a user says "it was slow around two", the evidence is already there.

  • Anomalies you never wrote a rule for. Unknown hosts, port scans, beaconing to the outside, and flows that only go one way are surfaced on their own pages, from the traffic itself.
  • "Slow" gets a number. Handshake and round-trip latency per conversation, DNS failures and slow resolvers, and TLS versions and ciphers that should have been retired.
  • From a site to a single packet. Site overview, top talkers, VLAN matrix, conversations, then the flow, then the packet inspector, field by field with the bytes beside it. Every step is a link.
  • It ties back to everything else. A bandwidth spike, an incident window and a firewall deny all link to the conversations that were on the wire at that moment.
ACME-HQ · capture point: core uplink Streaming
41 segments · 100 MB each · 8 days retained
Flows · last hour 184,206
Conversations 9,412
Unknown hosts 3
DNS failures 2.1 %
TLS below 1.2 14 hosts
Conversations · by bytes 14:20 to 14:52
FlowServiceBytesRTT
10.0.12.40 → 10.0.2.15 SMB 1.84 GB 0.9 ms
10.0.31.7 → 198.51.100.24 HTTPS 412 MB 22 ms
10.0.40.118 → 10.0.2.53 DNS 3.1 MB 640 ms
10.0.21.9 → 10.0.2.20 TLS 1.0 88 MB 1.4 ms
Anomalies · last 24 h
Beaconing10.0.44.12 → 203.0.113.9
Every 60 s for 2 h 23 m, 143 identical 312-byte posts. Not on the service catalog.
Scan10.0.12.77
Touched 412 ports on 28 hosts in 4 minutes. First seen on this VLAN today.
Unknown host10.0.40.201
Not in inventory. VLAN 40, first seen 09:12, talking to the print server.
Asymmetric10.0.21.30 → 10.0.3.8
Requests seen, replies never. Probably a routing or ACL problem, not the app.
FirewallDENY 14:31:07
Matched to 10.0.31.7 → 198.51.100.4:445 within 10 s. The rule, and the conversation it killed, on one line.
Inspecting packet frame 812 · 14:31:07.412 · 10.0.31.7:51422 → 198.51.100.24:443 Source: full dissection
← 811 of 1,204 in flow 813 →
Dissection tree · click a layer to expand
frame(12 fields)
frame.number:812
frame.time:14:31:07.412381
frame.len:1514 bytes
frame.protocols:eth:ethertype:vlan:ip:tcp:tls
eth(6 fields)
vlan(5 fields)
vlan.id:31
vlan.priority:0
ip(14 fields)
ip.src:10.0.31.7
ip.dst:198.51.100.24
ip.ttl:63
ip.flags.df:1 (Do not fragment)
ip.len:1500
tcp(18 fields)
tcp.srcport:51422
tcp.dstport:443
tcp.seq:88213
tcp.ack:4410
tcp.flags:0x018 [PSH, ACK]
tcp.window_size:501 (× 128 = 64,128)
tcp.analysis.ack_rtt:0.021 s
tls(5 fields)
tls.record.version:TLS 1.3 (0x0304)
tls.record.content_type:Application Data (23)
tls.record.length:1448
Bytes · TCP header highlighted
000000 1b 44 11 3a 9f 3c 2a 6d 7e 21 44 81 00 00 1f..D.:.<*m~!D....
001008 00 45 00 05 dc 4a 2f 40 00 3f 06 8c 11 0a 00..E...J/@.?.....
00201f 07 c6 33 64 18 c8 de 01 bb 00 01 58 a5 00 00...3d.......X...
003011 3a 80 18 01 f5 7c 0e 00 00 01 01 08 0a 2e 41.:....|........A
00409c 10 00 5a 3b 77 17 03 03 05 a8 4f 9d 21 b0 6e...Z;w.....O.!.n
00503c 88 2a 51 e0 17 44 0b 9a fe 73 21 0c 5d 88 e2<.*Q..D...s!.].

Every packet in every flow opens like this, straight from the stored segments. No export, no laptop, no second tool.

Critical Incident #4821 · root cause
opened 4m 12s ago
Root cause 1 frame
Alarms folded in 12
Hosts affected 340
Priority Core closet
ACME-HQ-COREup · 0.3 msACME-HQ-MDF-01ROOT CAUSE · frame downlast ping 4m 12s ago · trap: linkDown Gi1/0/41ACME-HQ-IDF-03suppressed · child of MDF48 ports · 31 hostsACME-HQ-IDF-07suppressed · child of MDF96 ports · 62 hosts+ 10 more IDFsall suppressed247 hosts31 hosts62 hosts247 hostsOne incident to work. 340 hosts explained. 12 alarms you never had to read.
Timeline
14:27:03Trap linkDown Gi1/0/41 received from ACME-HQ-MDF-01. Pings to the frame stop.
14:27:0512 downstream alarms folded under the MDF as consequences. None of them page anyone.
14:27:06Incident #4821 opened as Critical. Priority set from location: core closet, 340 hosts.
14:29:40Operator opened Terminus on the affected devices from this page.
14:31:12MDF answering pings again. Children clearing on their own, incident held open until the last one does.
Open Terminus on affected devices Impact map Weather at site
Respond

Twelve alarms in. One incident out. You already know where to go.

When a distribution frame fails, every switch behind it goes dark, and a traditional NMS pages you for each one. The on-call engineer then reads forty alerts to find the one that matters. IRIS knows how your closets connect, so it files one incident, names the frame that failed, and lists everything behind it as a consequence rather than a separate emergency.

  • "How bad is it" is answered before anyone asks. Every incident carries its blast radius: which closets, how many hosts, which sites, on a map.
  • Priority follows location, not alphabetical order. A core closet outranks a lab switch without anyone tuning a rule, and the frame that keeps coming back gets flagged so you fix the cause instead of the symptom.
  • Hand-over notes write themselves. Daily and weekend shift reports list what opened, what closed and what is still burning, so the next engineer starts informed instead of scrolling.
  • Context you would otherwise go looking for. Weather alerts and radar sit beside the incidents they explain, so a storm-side outage is recognised as one before anyone drives out.
Root cause analysis

It reads the sensors so nobody has to guess in the meeting.

Knowing which frame failed is half the answer. The other half is why, and that usually takes a senior engineer an afternoon of pulling logs. IRIS runs the evidence it already has, sensor history, UPS events, PoE draw, CPU and memory, interface errors and recent config changes, through seven cause categories and gives each a verdict with the evidence attached. What you get is a ranked explanation and a to-do list, not a pile of graphs.

  • Verdicts, not vibes. Power, cooling, environment, module thermals, load, PoE and network are each marked primary, contributing, ruled out or not enough data, with a confidence and the reading that decided it.
  • Recommendations by urgency. Immediate, short-term and long-term actions come with the analysis, so the post-incident review starts from a list instead of a blank page.
  • Repeat offenders have a pattern. Per-host analysis plots incidents by hour and weekday across 90 days. A switch that drops at two in the morning on Tuesdays is a backup job, and now you know.
  • Honest about gaps. If a device is not in SNMP monitoring, the analysis says so and tells you to add it, rather than pretending a verdict.
Critical Incident #4821 · root cause analysis
ACME-HQ-MDF-01 · analysed 14:31:40
Primary cause · 92 % confidence Utility power lost at HQ MDF. The UPS carried the frame for 21 seconds, then its output dropped. Battery in ACME-HQ-UPS-01 is 3.1 years old and was already flagged expired. Twelve downstream closets went dark as a consequence, not a cause.
CategoryVerdictConfidenceEvidence
PowerPrimary92%UPS ACME-HQ-UPS-01 to battery 14:26:41, output off 14:27:02, frame dark 14:27:03
PoEContributing55%Budget at 88 % before the drop; inrush on restore tripped two ports
EnvironmentalRuled out95%Ambient 22 °C, device 31 °C, well inside range
CoolingRuled out90%All fans nominal on the last three polls
Module thermalRuled out90%Module-to-ambient delta 9 °C
LoadRuled out90%CPU 12 %, memory 41 %, no spike in rollups
NetworkNot enough data30%Uplink counters stale during the outage window
Recommendations
ImmediateCheck UPS status and verify utility power at HQ MDF.
Short-termInspect circuit breakers and power distribution in the closet.
Long-termReplace the ACME-HQ-UPS-01 battery. It is 3.1 years old and flagged expired.
ACME-EAST-IDF-12 · 90 days High risk
Incidents9
Median outage6 min
Hosts behind it58
Hour of day7 of 9 at 02:00
0006121823
Day of weekTuesdays
M
T 7
W
T 1
F
S 1
S
Finding · critical Seven of nine incidents start within four minutes of 02:00 on a Tuesday, and the uplink hits 100 % in the same window. This is the weekly backup job saturating Gi1/0/48, not a failing switch.
Not monitored by SNMP yet? The analysis says so, falls back to ping and topology evidence, and recommends adding the device so the next incident gets the full treatment.
Execute

The fix is one tab away, not two hundred SSH windows.

Monitoring tools tell you something is wrong and then leave you to open a terminal, find the addresses and log in one switch at a time. IRIS ships its own browser terminal, Terminus. Launch it from the incident and the affected devices are already connected. Type a command once and every switch answers; click any one of them to read its output alone.

  • No pre-work. IRIS recognises Cisco IOS, Linux and the rest on connect, so the right prompts and commands just work.
  • "What changed?" takes seconds. Every collected config is versioned with a side-by-side diff, so the change that broke Friday is found before the rollback is even discussed.
  • Safe at scale. Batches throttle themselves per subnet and pause when logins start failing, so a mass change cannot lock out a site or flood a WAN link.
  • The post-mortem is already written. Every command, on every host, by every operator is in the audit log, so "who changed that" is a search, not an interrogation.
  • Packet capture without the laptop and span port. Flows, DNS health, TLS hygiene, unknown hosts, scans and beaconing, from the same screen as the incident.
  • Firewall events explained. Cisco firewall logs are matched to the captured flows around them, so a block rule firing is tied to the conversation that triggered it.
Terminus SSH
254 / 254 connected
Target hosts
10.0.50.0/24 IPv4 CIDR 254 hosts
Broadcast
1. show version | include uptime Cisco
2. show running-config | include hostname Cisco
3. write memory SSH
254 hosts × 3 commands = 762 jobs · ETA ~3m 49s
Primary host · ACME-HQ-IDF-07 · 10.0.50.45
ACME-HQ-IDF-07#show version | include uptime
ACME-HQ-IDF-07 uptime is 41 weeks, 2 days, 6 hours
ACME-HQ-IDF-07#show running-config | include hostname
hostname ACME-HQ-IDF-07
ACME-HQ-IDF-07#write memory
Building configuration...
[OK]
ok: archived running-config · diff: 0 lines
ACME-HQ-IDF-07# 
Why not a cloud NMS

Your data never leaves. Your bill never surprises.

Cloud-managed monitoring means your switch inventory, credentials and traffic patterns live on someone else's servers, on a per-device subscription that climbs every renewal. IRIS runs on one box inside your network. No agents on your switches, no telemetry to us, and no procurement call to add a closet.

See pricing
Single server Runs on a single Linux box you already know how to patch. One installer, one upgrade path, no appliance to buy.
Per-operator credentials Each engineer's SSH credentials stay theirs. Four permission roles and two-factor sign-in mean the intern can look but not type.
Complete audit trail Who ran what, on which host, when. The compliance question answered without a spreadsheet.
Retention you control A year of history stays fast to chart, and captures and logs prune on schedules you set, not ours.
Pricing

One dollar per host per year. Two sizes, no modules, no quote.

Network monitoring is usually priced per device, per feature module and per year, behind a sales call. IRIS is $1 per host per year with every feature included, in two sizes. A host is anything IRIS watches: a switch, an access point, a UPS, a server. Pick the size that covers your count and you are done.

10,000 hosts District
$10,000 per year

Dozens of sites, hundreds of frames, one watchboard for the NOC.

  • Up to 10,000 monitored hosts
  • Every feature included
  • Self-hosted, your data stays yours
Request a demo
Optional, on any plan

Would rather not run it yourself? We will.

The per-host licence is the same either way. These add the people.

Managed We run IRIS on your server
$1,000 / month

You provide the Linux box inside your network. We install IRIS, keep it patched and upgraded, watch the queues and pollers, and fix it before you notice. Your data still never leaves the building.

Hosted and managed We run it on ours
$1,500 / month

Everything in Managed, plus we host the server. Includes up to $500 a month of server cost. If your fleet needs more than that, the difference is billed at actual usage, itemised, no markup surprise.

More than 10,000 hosts? Same dollar, same rules. Talk to us about a multi-site rollout.

See what your last outage would have looked like.

Bring a host count and the incident that hurt most last quarter. We will walk through when IRIS would have noticed, what it would have called the root cause, and how many alarms you would not have read.