An outage is a full window of silence, not one missed read.

Fault is the first view on AIM's own screen. AIM collects from each application it watches — Fiduciary, A&R and TestPulse — every 60 seconds, under one collector identity per application. AIM's own heartbeat comes first, so you know the screen is current before you believe anything on it. Every attempt records what actually happened, and an application is declared unreachable only after a full window passes with no answer.

60 s collection AIM's heartbeat first 8 distinct outcomes Full window before unreachable No application token in the browser

What an attempt can say

Every outcome is its own word. None are folded into "down".

A timeout, a refused login and a missing route need different people to fix them. So AIM keeps each outcome distinct and shows the measured cause next to it, instead of collapsing everything that is not an answer into one red light.

OUTCOMEANSWER?WHAT IT MEANS

answeredyesThe endpoint replied. This says AIM was answered, not that the application is healthy: the reply itself says that.

timeoutnoThe connection was made, but no reply came back in time.

unreachablenoAIM could not connect to the application at all.

auth_failednoThe application rejected AIM's collector identity.

forbiddennoThe identity was accepted but is not allowed to read that endpoint.

route_absentnoThe endpoint does not exist on the application as deployed.

disablednoCollection for that endpoint is switched off on purpose.

throttlednoThe application asked AIM to slow down.

One miss is not an outage. A single failed read is recorded with its cause, and the card keeps saying REACHABLE. Only when a full window passes with no answer does AIM declare the application unreachable, and say who owns the failure.

Recorded · 2026-10-15

Fault and recovery, start to finish.

Fiduciary's API is stopped for real. AIM keeps collecting, shows the first failures and their cause, waits out the full window, declares Fiduciary unreachable, and then reports the recovery on the next successful read once the API is back.

▶ AIM: fault and recovery

Engineering by Tarik Riley

AIM: fault and recovery. All three applications reachable; Fiduciary's API stopped; the first failed attempts with their measured cause while the card still says REACHABLE; UNREACHABLE after a full window, failure owner: application; then recovered on the next successful read. Long waits are time-lapsed and marked on screen. Narrated, with captions.

AIM's screen before the fault: AIM's own heartbeat healthy, and the Fiduciary, A&R and TestPulse cards all marked reachable, with every endpoint answered and fresh. — **1 · All reachable.** AIM's heartbeat is healthy and Fiduciary, A&R and TestPulse all answer.

AIM's screen just after Fiduciary's API was stopped: the Fiduciary card still says reachable, while its endpoints show the first failed attempts with the measured cause of each failure. — **2 · First failed attempts.** Fiduciary's API is stopped. The first attempts fail and the measured cause is shown, while the card still says REACHABLE. One miss is not an outage.

AIM's screen after a full window with no answer from Fiduciary: the Fiduciary card marked unreachable, the failure owner shown as application, and the A&R and TestPulse cards still reachable. — **3 · Unreachable.** After a full 4 min 40 sec window with no answer, Fiduciary is declared UNREACHABLE. Failure owner: application.

AIM's screen after Fiduciary's API was started again: the Fiduciary card back to reachable with its endpoints answered and fresh, on the first successful read. — **4 · Recovered.** Fiduciary's API is back. The card returns to reachable on the next successful read.

How this was recorded

Recorded on 2026-10-15 in a real browser against the deployed lab. Fiduciary's API was really stopped and really restarted; nothing on screen is mocked. The long waits are time-lapsed, and each time-lapse is marked on screen. All data is synthetic. The narration is a synthetic voice. AIM's screen is still in review, so details may change before it ships.

Talk to us about applying FCAPS to your AI.

If you run an operations team that already speaks FCAPS, Fault is the place to start: what the AI answered, when, and who owns it when it stops.

Talk about AIM AIM overview →

An outage is a full window of silence, not one missed read.

Every outcome is its own word. None are folded into "down".

Fault and recovery, start to finish.

▶ AIM: fault and recovery

How this was recorded

Talk to us about applying FCAPS to your AI.

Request the Fiduciary preview

A&R design partner program

Talk about AIM

Contact BMI2

Message sent