Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
"Fae" Grace Meadows
Reliability Monitor is the day-by-day summary of every crash, failed update and hardware error Windows has recorded. How to open it, read the stability index and the five rows, trace a critical event to its faulting module or stop code, fix an empty history, and read the same data across a fleet with PowerShell.
A user says the PC "crashes sometimes", can't say when, and the Event Viewer on that machine holds forty thousand entries. Windows already keeps a day-by-day summary of every crash, failed update and hardware error, laid out on a single chart. Reliability Monitor is that chart, and it turns a vague complaint into a dated list in about a minute.
Reliability Monitor is a timeline view built into every supported version of Windows. It reads the same failure events that land in the event logs, groups them by day, and draws a stability index across the top. Microsoft's Windows Server training module describes the index as a number that "ranges from 1 to 10, where 1 represents the least-stable server state and 10 represents the most stable state".
There are three ways in. The fastest is the Run box: press Windows+R and type perfmon /rel. You can also search the Start menu for "reliability" and pick View reliability history, or go through Control Panel, Security and Maintenance, Maintenance. All three open the same window.
Nothing needs installing or switching on for a Windows 10 or 11 client. The data has been collecting since the machine was built, which is the point: you get the history from before the ticket existed.
The top line is the stability index. A flat line near 10 is a quiet machine. Every new failure drags it down, and the line climbs back slowly over the days that follow without new failures. A line that saws up and down every few days tells you more than any single low point does, because it means the fault keeps coming back.
Under the line sit five rows of icons, one column per day, or per week if you switch View by at the top. Microsoft's training module names the failure categories as application failures, Windows failures, miscellaneous failures and warnings, and a fifth row carries information events. In practice the rows read like this:
A red circle is a critical event, a yellow triangle is a warning, and a blue "i" is information. The information row is the one technicians skip and should not. When the Windows failures start on the same day a driver update landed, the chart has done the diagnosis for you.
The r/Windows11 thread below was posted as a tip of the week, and the replies keep landing on the same two points: it gives a clearer picture than Event Viewer, and it is the first thing people check when a friend's PC misbehaves.
Click a day and the details table fills in with every event for that day, critical first. Each row has a source, a summary such as "Stopped working" or "Hardware error", and an action link. Click View technical details and you get the part that matters: the problem signature.
For an application crash, the signature names the faulting application, its version, and the faulting module, the DLL that was running when it died. The module is your lead. A module from a third-party plug-in, an antivirus filter or a printer driver points at that vendor. A core Windows module such as ntdll.dll or KERNELBASE.dll usually means the app passed it bad data, so the fix still sits with the app, as Dell's own Reliability Monitor guide notes when it walks through the same case.
For a Windows failure, the signature carries a problem event name and a code. A BlueScreen event gives the bug check code, which is the stop code from the blue screen the user may never have read, and our blue screen guide maps the common ones. A LiveKernelEvent is a hardware or driver fault that Windows recovered from without a blue screen, and its code points at the subsystem. Code 141 is a display engine that stopped responding, for example, which is what pointed the replies in the r/techsupport thread below at the GPU rather than the SSD the user had been about to replace.
If the stop code is one of the hardware ones, the next step is a hardware test rather than a driver hunt. Our guide to the WHEA uncorrectable error covers the CPU, memory and storage checks in order, starting with the built-in memory test.
Reliability Monitor is the index. Event Viewer is the full text. Once the chart has given you a timestamp, open eventvwr.msc, go to the System log, and filter the minutes around it. Disk and controller warnings just before a crash, a service that failed to start just after a reboot, or Kernel-Power 41 next to an unexpected shutdown are the context the summary leaves out.
The two tools disagree in one useful way. A sudden power loss leaves no crash report, so Reliability Monitor shows only a miscellaneous "Windows was not properly shut down" entry. Event Viewer shows the matching Event ID 6008 at the next boot, and our guide to Event ID 6008 covers how to tell a power cut from a hard hang. If the chart shows those entries with no blue screen and no hardware error around them, check the power supply and the UPS before the drivers.
For a closer look at the window itself, Steve Staves walks through the chart, the details table and the technical details link on a live machine.
A blank chart has three common causes, and they are worth checking in this order.
The first is a server. Reliability data on Windows depends on a Group Policy setting called Configure Reliability WMI Providers, under Computer Configuration, Administrative Templates, Windows Components, Windows Reliability Analysis. Microsoft's class reference is plain about the defaults: "On Windows client systems, the policy is enabled by default. On Windows Server systems, the policy is disabled by default." It also warns that disabling the policy "will clear existing data within one hour", so a baseline that turned it off on workstations explains a chart that was full last month and empty now.
The second is the scheduled task that feeds the chart. Microsoft's support article for the blank-chart symptom explains that the data "is provided by the RacTask task", which lives in Task Scheduler under Microsoft, Windows, RAC and is hidden by default. On Windows Server 2012 R2 the trigger that runs it regularly is disabled after its first run, and the fix is to show hidden tasks, re-enable the trigger, and set WMIEnable to 1 under HKLM\SOFTWARE\Microsoft\Reliability Analysis\WMI, then restart. The same check is the first thing to try on a client that went blank after a tuning script.
The third is a damaged data store, which shows up as a chart that resets every few days. Reset guides exist, but they delete the history you were trying to read, so export what is there first.
At the bottom of the window, Save reliability history writes everything to an XML file. Do this before reimaging a machine, before a reset of the data store, or before you hand a hardware fault to a vendor who wants proof. View all problem reports opens the list of every report on the machine, which is the faster view when you want one app's crash history rather than one day's.
Every help desk has a version of this ticket:
The chart is one machine at a time. The data behind it is not. Windows exposes it through two WMI classes: Win32_ReliabilityStabilityMetrics holds the stability index over time, and Win32_ReliabilityRecords holds the events, with the source, event ID, product name and message for each. On a client, both answer without any setup.
powershellGet-CimInstance Win32_ReliabilityStabilityMetrics | Select-Object -First 1 SystemStabilityIndex, EndMeasurementDate Get-CimInstance Win32_ReliabilityRecords | Where-Object { $_.TimeGenerated -gt (Get-Date).AddDays(-14) } | Group-Object SourceName, EventIdentifier -NoElement | Sort-Object Count -Descending | Select-Object -First 5 Count, Name
The first command returns the current index. The second counts the most frequent failure sources over the last two weeks, which on a healthy machine is a short list and on a sick one names the culprit. Run the pair across a client's devices and sort by index, and the five worst machines in the fleet surface before their users open tickets. On OpenFrame that is one script run across a client's devices with the output collected in one place.
Sort the results by event source as well as by machine. The same faulting module on a dozen laptops is a driver or an app rollout, not twelve hardware faults, and the DRIVER_IRQL_NOT_LESS_OR_EQUAL guide covers the next step when that module is a driver.
Reliability Monitor is the dated summary of every failure a Windows machine has recorded. Open it with perfmon /rel, read the information row against the failure rows, and use View technical details for the faulting module or the stop code before you open Event Viewer. If the chart is blank, check the WMI provider policy and the RacTask trigger, and save the history before anything resets it. Across a fleet, the two WMI classes turn the same data into a sorted list of the machines that need you first.
When the stop code points at memory, the next read is our Windows Memory Diagnostic guide.
Lead AI Fairy
Some things defy easy explanation: magic dust, the northern lights… and Flamingo’s AI Angels. Think Charlie’s Angels, reimagined with automation brains and serious RMM (Remote Monitoring & Management) chops. Weird? A little. Effective? Absolutely. That’s the job.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.