01
Map it
An agent in each data centre maps your servers, VMs, databases, switches and cloud, and how they all connect. It only ever dials out.
AI on-call for European ops teams
Every alert investigated. Every fix approved. Always learning.
Built for estates that aren’t all Kubernetes: VMware, Windows, databases, switches and cloud. OpsAct maps it all, finds the cause when something breaks, lines up the fix and waits for your yes. Then it remembers, so next time is quicker. Hosted in the EU.
- Read-only until you approve
- Credentials stay on your site
- Maps every dependency
- Learns from every incident
Checkout, production EU
Root cause foundinc-2417- Paged by Datadog: checkout p95 above target00:00
- Grouped 14 alerts from 4 tools into one incident00:04
- Loaded the checkout path from the discovery map00:09
- No deploys or config changes in 24 hours. Ruled out a bad release.00:21
- Postgres write latency rose from 4 to 310 ms00:52
- Disk on
db-orders-03is 94% used01:10 - Matched incident 2291 from August: same table, same disk01:58
- Wrote a 3-step plan from the disk runbook02:41
Checkout is slow because db-orders-03 is out of disk.
- 1Snapshot the volumeNo impact
- 2Grow
data-db-orders-03from 500 to 750 GiBChanges production - 3Watch latency and errors for five minutesNo impact
Press and hold. With a keyboard, hold Enter or Space.
An example incident. Hold the button to approve the fix.
Discover. Understand. Act.
What happens when something breaks
The same steps your on-call engineer takes at 3am, without the twelve open browser tabs.
02
Dig in
An alert fires. OpsAct checks the likely causes against your monitoring and the map, and shows its working, including what it ruled out.
03
Line up the fix
It picks a reviewed runbook and marks every step: harmless, changes production, or ticket only.
04
You say yes
Approve in Slack or the web app. It runs one step at a time, checks each one, and stops if anything looks off. The change record writes itself in ServiceNow or Jira.
Product walkthrough with an example estate. Under 2 minutes, with music.
Read it as text
- Connect the tools you already use. 126 alert sources to choose from.
- New Relic sends alerts by webhook. OpsAct can set it up for you.
- A test alert arrives. OpsAct maps its fields to your services and hosts.
- Now Nagios, through the agent already running in your Dublin data centre.
- Two more sources, connected in under a minute. Nothing opens inbound.
- Discovery already spotted MongoDB in Frankfurt. Give it a read-only login.
- Choose what it may do: discover, diagnose, and later, fix.
- Logins stay in your own vault. Your agents read them, OpsAct cloud never does.
- Agents scan your data centres and clouds. Read-only, and they only dial out.
- Where it finds something it can’t read yet, it says so, and drafts a way in.
- Then it maps what depends on what, from the web front end down to the disk.
- MongoDB and RabbitMQ are new, so OpsAct drafts runbooks for them.
- Each runbook is a flowchart. Steps that change production ask first.
- 1,284 alerts today, merged and grouped into 3 incidents.
- A late alert from the replica? It explains where it belongs.
- It loads the checkout path from the map and tests every likely cause.
- Root cause in 2 minutes 41 seconds: db-orders-03 is out of disk.
- The fix comes from a reviewed runbook, and it waits for a yes.
- Snapshot, grow the disk, then watch. Each step is checked before the next.
- Fixed and verified. The change record writes itself, and the fix goes into memory.
- Ask questions in plain words, in the incident channel or the web app.
- It answers from the evidence, not a guess.
- Which databases fill up next? It answers with live numbers and owners.
What changes
Fewer pages. Faster fixes. No surprises.
What the example on this page looks like for an on-call team.
Every alert looked at
OpsAct reads every alert as it arrives, merges the repeats and groups the rest using your dependency map. On a busy day in the example estate, 1,284 alerts became 3 incidents, and only one needed a person.
The cause, before anyone logs in
By the time the on-call engineer opens the incident, the investigation is done: the cause, the evidence, what was ruled out and a plan to fix it. In the example, that took 2 minutes 41 seconds.
Nothing changes without a person
Steps that change production wait for an approval, run one at a time and are checked before the next. Every action is logged for your change records and for the EU AI Act.
Problems that stay fixed
Every fix becomes a runbook, and the root cause is ticketed to the team that owns it. In the example, OpsAct matched today’s incident to one from August, same table and same disk, and reused the fix your team approved then.
These figures come from the example estate shown on this page, not from customers. OpsAct tracks time to root cause, time to fix and out-of-hours pages from day one, so you can see your own before and after.
Proves itself first
Trust it because you’ve checked it
A confident wrong answer at 3am is worse than none. So OpsAct shows you how it does on your own incidents before it touches anything.
Replay last month
Give it read-only access and a month of alert history. It investigates those incidents again, and you compare its answers with what your team actually found.
Shadow your on-call
It investigates live incidents read-only and posts its findings next to your team’s. Nothing runs. You see where it’s right, and where it isn’t.
Scores in the open
We publish how OpsAct does on public benchmark incidents, including the ones it gets wrong, so you can judge it on evidence, not a sales deck.
Runbooks
See what it will do before it does it
Every fix comes from a reviewed runbook. Each step shows the exact command and how risky it is, and nothing that changes production runs until a person approves it.
Postgres disk filling up5 steps, 1 changes production
- Check free space on the data volume
df -h /var/lib/postgresqlRead only - Find what is growing: tables, WAL or logs
pg_total_relation_size(...)Read only - Snapshot the volume first
snapshot data-db-orders-03No impact - Grow the volume by 50%
resize data-db-orders-03 +250 GiBChanges production - Watch write latency for five minutes
p95 write latency < 20 msRead only
Step 4 waits for your approval, held in Slack or the web app
If any check fails, OpsAct stops and tells you what it saw.
Runbooks cover the systems most estates actually run, from VMware and Windows to databases and switches. Where it finds something with no runbook, OpsAct drafts one for you to review.
VMwareVMware datastore fullOld snapshots and thin disks, found and fixed through vCenter
SQL ServerSQL Server tempdb fullWhich session is filling it, and a safe way to free it
KafkaKafka consumer lagSlow consumers, stuck partitions and rebalances
WindowsWindows Server C: drive fullLogs, updates and dumps, cleaned with an approved step
ElasticsearchElasticsearch disk watermarkShards blocked from writing, and how to unblock them
Diagnose onlySwitch port flappingErrors and link changes on the port, with a ticket for the network team
Discovery and dependency mapping
See how everything connects. Ask what breaks.
Most AI incident tools only know what your monitoring tells them. OpsAct finds everything you run and works out how it fits together. Then you just ask.
Dependency map, Dublin data centreWhat runs on what, from services down to storage and network. Click anything to see what it touches.
Map as of
ServicesData and platformsHostsStorage and networkServicesData and platformsHostsStorage and network
| System | What it is | Link to esx-dub-07 | Found by | Last change |
|---|---|---|---|---|
| Service | Depends on it | Kubernetes API | 2 weeks ago | |
| Service | Depends on it | Kubernetes API | 2 weeks ago | |
| Service | Depends on it | Kubernetes API | 5 days ago | |
| Service | Depends on it | Kubernetes API | 3 days ago | |
| Kubernetes cluster | Depends on it | Kubernetes API | 3 days ago | |
| Kafka cluster | Not connected | SSH | 1 month ago | |
| PostgreSQL database on a Linux VM | Depends on it | vCenter and SSH | Today 09:12 | |
| SQL Server on a physical server | Not connected | WinRM | 5 days ago | |
| VMware host | Not connected | vCenter API | Today 09:12 | |
| VMware host | Selected | vCenter API | Today 09:12 | |
| Core switch | Not connected | SNMP and LLDP | 6 months ago | |
| VMware datastore | Not connected | vCenter API | 2 months ago | |
| NetApp storage array | Not connected | ONTAP API | 4 months ago | |
| Core switch | Not connected | SNMP and LLDP | 6 months ago |
Swipe sideways to see the whole map.
Depends on itIt depends onConfirmedSeen in traffic only
Ask OpsActAbout your estate
If I patch esx-dub-07 tonight, what's affected?
Dependency map, Dublin data centre
esx-dub-07 runs db-orders-03, which moved there at 09:12 today, and half of the k8s-dub cluster. So all four services sit on it: checkout, orders, invoicing and returns. Move db-orders-03 back to esx-dub-08 and drain the k8s-dub nodes first, and nothing should go down.
Highlighted on the map
Example questions
- Finds everything
Network, servers, VMware, storage, Kubernetes and cloud, through read-only logins. One agent group per site, nothing to install on every server.
- All the way down
Dependencies come from config, network neighbours, service traffic and your CMDB. Every link says how OpsAct knows it. Wrong? Fix it on the map.
- Never out of date
Changes land on the map within about a minute. No CMDB clean-up project required.
- Learns new kit
Finds a device it can't read? It drafts a read-only collector, tests it, and asks you before using it.
Your first map within 30 minutes of installing the agent.
Always learning
It remembers what worked
Most tools start every incident from scratch. OpsAct doesn't. It learns from each one, and from every "no, not like that".
- Seen it before
Every incident, its cause and its fix go into memory. When the same table fills the same disk again, OpsAct starts from the fix that worked.
- Learns from every no
A declined plan comes back with your reason, and OpsAct drafts another. Corrections to the map are kept, so the next investigation sees your estate as it really is.
- Writes the runbooks you're missing
For everything it finds, from switches to the apps running on them, OpsAct checks it has runbooks to diagnose and fix it. Where there are none, or it spots trouble building, it drafts new ones. A person reviews them before they can run.
- Turns hand fixes into runbooks
When your team fixes something by hand, OpsAct drafts a runbook from it. A person reviews it before it can run.
- Builds a track record
Every runbook keeps score, such as approved 12 of 12 and rolled back 0. That record is what lets you hand over more, one runbook at a time.
Seen this beforememory
Incident 2291 · 14 AugustUsed today
Same table filled the same disk. Growing the volume fixed it in 6 minutes.
Incident 2104 · 2 June
Autovacuum blocked by a long transaction. Different cause, ruled out today.
New runbooks draftedWaiting for review
Diagnose and clear Kafka consumer lag. Drafted for kafka-dub, which discovery found with no runbooks yet.
Restart a stuck IIS application pool. Learned from incidents 2388 and 2402, both fixed by hand.
Track recorddb-orders-03
12 of 12approved
0rolled back
Grow a database volume. Enough of a record to consider Do it, then tell me.
Learning stays inside your OpsAct account, hosted in the EU. No customer data is used to train AI models.
Coverage
Built for estates that aren't all Kubernetes
Most AI incident tools were built for the cloud. Your estate probably has a few things that weren't.
Servers
LinuxWindows ServerIIS
Virtualisation
VMware vSphereESXi hostsDatastores and snapshots
Containers and cloud
KubernetesAWSAzure
Databases and queues
PostgreSQLMySQLSQL ServerOracleMongoDBRedisElasticsearchKafkaRabbitMQ
Network switches
Cisco IOS and NX-OSArista EOSJuniper Junos
Server hardware
Dell iDRACHPE iLOAny Redfish controller
Switches, server hardware and Oracle start as diagnosis only: OpsAct finds the cause and opens the ticket.
Physical serverHardware health through iDRAC or iLO. A failing part becomes a ticket with the evidence attached.
Virtual machineThe hypervisor underneath: datastore space, old snapshots, CPU contention, host failures. Many fixes run through vCenter.
Cloud instanceThe provider's API, through a read-only role for diagnosis.
Reads from the monitoring you already run
PrometheusDatadogElasticGrafanaZabbixMore than 100 others
Approvals and records go to
SlackServiceNowJiraThe OpsAct web app
Vulnerabilities
A new vulnerability at 7am. Which of your systems have it?
OpsAct already knows what runs where. When a vulnerability is published, it shows which systems are exposed, which to fix first, and tracks the fix to the last one.
PHP2ShellCVE-2026-109618, CVE-2026-109619
10 of 11 PHP systems affected. 4 reachable from the internet.
| System | What runs | Reach | Priority |
|---|---|---|---|
| web-dub-03 | PHP 8.3.30PHP-FPM, 3 pools | From the internet | Patch now |
| shop-fra-01 | PHP 8.2.28Apache mod_php | From the internet | Patch now |
| billing-fra-04 | PHP 8.4.27Fix installed, restart needed | Internal | This week |
| cms-dub-02 | PHP 8.1.2Ubuntu build, fix backported | Internal | Fixed by backport |
- Finds what actually runs
Every PHP runtime that serves web requests, from FPM pools to Apache modules and containers. It reads your distribution's own fix data, so a backported fix isn't flagged as exposed.
- Puts the risky ones first
Systems reachable from the internet, flaws known to be exploited and business-critical services go to the top, each with a due date.
- Tracks the fix to the last system
One ticket per owner, listing their systems. OpsAct checks each fix, restart included, before it counts as done.
- Patches through your own patch tool
OpsAct never installs software itself. With an approved plan, it can start the patch job you registered in your own patch tool, such as AWX or Red Hat Satellite, in waves, and stop at the first failure.
Coming in 2027
Exceptions are recorded with a named owner and an expiry date, and the evidence for DORA and NIS2 comes out as one export.
Integrations
Works with the tools you already have
Nothing to rip out. OpsAct reads the alerts you already get and reaches your systems through read-only logins you control.
Alerts and monitoring
- Datadog
- Prometheus
- Grafana
- Zabbix
- Nagios
- Checkmk
- New Relic
- Dynatrace
- Sentry
- Splunk
- Elastic
- Amazon CloudWatch
- Azure Monitor
- Google Cloud Monitoring
- Pingdom
- Uptime Kuma
- PagerDuty
- Opsgenie
- Email and webhooks
- and more than 100 others
Systems it discovers, diagnoses and fixes
- VMware vCenter
- Windows Server
- Linux
- Kubernetes
- AWS
- Azure
- PostgreSQL
- MySQL
- SQL Server
- MongoDB
- Redis
- Kafka
- RabbitMQ
- Elasticsearch
- Network switches over SNMP and SSH
Chat, tickets and changes
- Slack
- ServiceNow
- Jira
Autonomy you grant
You decide how far OpsAct goes
Set it per environment and per runbook. Everyone starts at Ask first, and a clean record earns more rope.
OpsAct runs the plan after an engineer approves it.
Approve in Slack or the web app. Each approval is signed and recorded, and every step is checked before the next one runs.
Where everyone startsSafety
Your security team will have questions. Good.
Here are the short answers.
Read-only investigation
Investigating never changes anything. OpsAct reads metrics, logs and the map, and runs only read-only checks.
No shell, ever
The agent runs named actions with checked inputs. There is no command line for a model to type into.
Credentials stay home
Each system's login lives in your vault, on your site. The agent dials out over mutual TLS, so you open no inbound ports.
Signed, or it doesn't run
Every approval is signed. The agent refuses any request that is unsigned or has been changed since it was approved.
Check, then continue
Each step is verified before the next one runs, and the run stops at the first failure.
A complete record
Who approved what, what ran and what it found, in the audit log and in your change records.
DORA and NIS2
The regulator report, drafted before you ask
If DORA or NIS2 applies to you, a major incident starts a clock. OpsAct already has the timeline, the impact, the root cause and every action taken, so it drafts each report for you to check and send.
First notice
- DORA
- Within 4 hours of classing it as major, and no later than 24 hours after detection
- NIS2
- Early warning within 24 hours
Filled in by OpsActWhen it was detected, which services and systems are affected, the first estimate of impact and what has been done so far.
Update
- DORA
- Within 72 hours of the first notice
- NIS2
- Incident notification within 72 hours
Filled in by OpsActThe root cause and its evidence, customers and transactions affected from your monitoring, and the recovery steps taken.
Final report
- DORA
- Within a month of the last update
- NIS2
- Within a month of the notification
Filled in by OpsActThe full timeline, root cause, what was fixed, what will stop it happening again, and the change records.
OpsAct drafts. A person decides whether an incident counts as major, checks every report and sends it. Deadlines follow DORA Article 19 and NIS2 Article 23; your own regulator’s templates and rules apply.
EU sovereignty
Your data stays in the EU. Your people stay in control.
For European teams that have to know where their data lives, and show a person is in charge of the AI.
- EU infrastructure. The OpsAct service runs in EU data centres, and so do the AI models it uses.
- Data hosted in the EU. Incidents, findings and the audit log are stored in the EU. Credentials and raw data never leave your site.
- GDPR compliant. A data processing agreement as standard, and no customer data is used to train AI models.
- Sovereign when you need it. Run OpsAct in an EU sovereign cloud, or single-tenant in your own environment.
EU AI Act readyDesigned to the standard the Act sets for high-risk AI
- Human oversightArticle 14
- A person approves every change before it runs, and any plan can be declined.
- Record-keepingArticle 12
- Every investigation, approval and action goes into an append-only audit log.
- TransparencyArticle 13
- Each conclusion shows its evidence, its confidence and the causes it ruled out.
- Accuracy, robustness and cybersecurityArticle 15
- Typed actions, signed approvals, a check after every step, and an evaluation suite every AI model must pass.
Book a demo
See what it would have found last month
Tell us what you run. With your permission, we replay a month of your alerts through OpsAct and walk you through what it finds, from the first alert to the fix it would have proposed.
Plans from €1,500 a month for up to 250 systems. Every site and environment included.
Questions
What teams ask first
Not unless you let it. Investigation is read-only. Fixes come from reviewed runbooks, and in Ask first mode nothing runs until an engineer approves it. Do it, then tell me stays off until you switch it on for a specific runbook.