Live demo

AEON on a bank-shaped estate

A 1,000-rack data centre, a recovery site, a thousand branches and fifteen hundred ATMs: 10,976 devices, run on a single machine. We injected the faults that actually take a bank's branches offline and recorded what AEON did. Every number below was computed by AEON itself.

10,976devices: 1,200 racks across two data centres, 1,008 branches in 12 zones, 1,554 ATMs

1 alertwhen a zone hub failed and 287 devices behind it went silent, instead of 287

18 minwarning of a temperature breach, with the failing cooling unit named behind 250 servers

under 0.5 sfor every operator view but one, across the whole estate

What was real and what was simulated: the platform and its databases were real and running throughout. The estate and its readings were generated, because no physical equipment was involved. Faults were injected deliberately — a zone hub failing, a cooling unit degrading, internet banking slowing, replication to the recovery site slowing, ATMs on poor links dropping in and out — so there was something genuine to find. No device was controlled.

Open the full run in a new tab

What the test found

We would rather tell you

Running AEON at this scale found problems in AEON. They were fixed and tested before these figures were taken.

Alerts followed devices, not the network

A failed hub would have raised an alert for every branch behind it. Suppression now follows the network, so one fault produces one alert.

A rule could ignore part of itself

An alert rule could accept a filter AEON did not support and quietly drop it. Unsupported fields are now refused when a rule is saved.

And one we have not fixed yet

ATMs on poor links that drop in and out are not alerted, because AEON waits for a sustained outage. A rule for flapping links is being built.