--- title: "Blog" description: "Read about the background of our monitoring solution, new features and case studies" canonical: "https://www.rumvision.com/blog/new-analyse-your-alerts-and-health-checks-with-ai/" --- Breadcrumbs: [Home](https://www.rumvision.com/?format=md) > Blog # New: analyse your alerts and health checks with AI An alert tells you that something changed. A health check tells you what is wrong. Neither tells you why. Until now. From today, every alert and every health check in RUMvision has an Analyse this issue with AI button that explains the cause in plain language, based on your own real user data. ## Knowing something broke is only half the job If you've used RUMvision for a while, you know the drill. An alert lands in your inbox or Slack: *TTFB on desktop exceeded 800ms*. You open the alert history, see the number went from 1,176ms to 1,224ms, and then the real work starts. Was it one page template? One browser? A third party that got slower? A deploy somebody did yesterday? Answering that means opening the technical dashboard, slicing by page group, by device, by connection type, by third party, and comparing it all against the day before. Experienced users can do that in ten minutes. Everyone else files it under *look at later*, and later rarely comes. Health checks have the same problem from the other side. *LCP image lacks fetchpriority high on Product detail page for mobile* is a clear finding, but the developer who picks it up still has to work out which image, on which template, why it matters for this site specifically, and whether it is worth fixing before the other 28 open issues. We built RUMvision to make real user data understandable. The data was there. The *why* still took work. That is the gap this release closes. ![five-manual-steps-become-one-click.png](https://www.rumvision.com/file/upload/img/five-manual-steps-become-one-click.png) ## What's new: one click from alert to explanation Every row in your alert history and every open health check now has an **Analyse this issue with AI** button. Click it, and RUMvision reads the real user data behind that specific alert or issue and writes up what it finds: - **TL;DR:** one paragraph for the site owner. How bad it is, who is affected, and the single next step, in plain words. - **Verdict:** what the data shows, whether action is needed (fix, monitor, or nothing), and a confidence level with the reason behind it. - **Evidence:** tables comparing the right days, segments and metric phases, with the exact slice and date window stated for each. - **Actions:** the concrete thing to change (a template, an element, a resource, or the alert configuration itself) and how to verify it. If nothing needs doing, the list is empty. - **Caveats:** what the data could not settle, so you know where the uncertainty sits. The analysis never restyles the alert's own numbers. It runs its own queries against your field data, the same checks a RUMvision analyst would run, and only writes down what that data shows. A hypothesis the data rejected does not appear in the report. ![cleanshot-2026-10-20-at-131533.png](https://www.rumvision.com/file/upload/img/cleanshot-2026-10-20-at-131533.png) ## Alerts: from "TTFB exceeded 800ms" to "here's why" Open **Workflow → Alert history**. Each alert shows the metric, the value, the change versus the day before and the last 7 days, and which threshold it violated. Next to it, two actions: **Technical dashboard** (the manual route, still there) and **Analyse this issue with AI**. Take a real example from one of our own domains. On Sunday 27 September an alert fired: *INP on desktop regressed by more than 15% on the Homepage*. The alert compared that day with the day before and saw p80 go from 185 ms to 217 ms, a 17.3% increase. One click. The analysis queried the same slice for the surrounding weeks, compared like for like, checked the INP phases and the other templates, and came back with this: - **Verdict:** the alert compared a Saturday with a Sunday. Sunday's 217 ms sits next to the previous Sunday's 209 ms, and the two Sundays after it came in at 193 ms and 185 ms. Action needed: monitor. Confidence: high. - **Phases:** on matched Sundays, processing duration was 115 ms and 114 ms, input delay 13 ms and 14 ms, presentation delay 69 ms and 70 ms. No phase moved. - **Control group:** the Homepage's share of desktop interactions went from 29.4% to 29.9%, and all other templates combined stayed at 177 ms. No traffic shift, no site-wide change. - **Action:** change the alert from a 1-day main window against the 1 day before to a 2-day main window against the preceding 7 days, so weekends stop tripping it. - **Caveat:** the data does not identify a script or element as a cause, because there is no cause to find. That is the honest answer, and it is the one you want: no developer time spent chasing a weekend pattern, and an alert that will not fire on it again. When something did break, the same checks localise it to the template, the metric phase and the segment that moved, and the actions name what to change. Either way, the technical dashboard is one click away, already filtered to the same alert, if you want to see the evidence yourself. ## Health checks: not sure why an issue is open? Ask Health checks run automatically and open an issue whenever a page template fails a check: a missing `fetchpriority` on the LCP image, render-blocking resources, an unoptimised hero, layout shifts from late-loading fonts. Each issue already links to a **More info** article and the technical dashboard. Now it also has **Analyse this issue with AI**. Where the alert analysis asks *why did this change*, the health check analysis asks *why does this matter here, and what exactly should I change*. Take the issue *LCP image lacks fetchpriority high on Product detail page for mobile*. The analysis tells you: - **Which resource:** the actual LCP element on that template, as seen in real page loads, and how often it's the same image. - **How much it costs:** how late the browser starts fetching it today, and what LCP looks like on this template versus templates where the priority is set. - **The fix:** the attribute to add, where in the template it belongs, and what to watch for if the image is lazy-loaded or injected by JavaScript. - **Priority:** how this issue ranks against your other open issues, so you fix the one that moves your Core Web Vitals first. Once the fix is live, the health check picks it up on its next run and closes the issue automatically, as it always has. ![cleanshot-2026-10-20-at-131616.png](https://www.rumvision.com/file/upload/img/cleanshot-2026-10-20-at-131616.png) ## It's your data, not a generic answer Plenty of tools will tell you that `fetchpriority="high"` is a good idea. What makes this different is that the analysis runs on your real user monitoring data, scoped to that alert or that issue. Behind every answer sits the same data you see in the dashboards: Check What it settles Like for like The same weekday and the same slice, named by date, so a Saturday is never judged against a Sunday Trend The day-by-day series before and after the alert, so a one-day blip, a weekly pattern and a real regression look different Slice discipline One set of filters (device, template, navigation type) used for every number, with sample counts on every row Localisation Which template, element, script, browser or segment carries the change Control group The complement of the blamed segment. If the rest is just as slow, the cause is site-wide, not that segment Mechanism Which metric phase moved (for INP: input delay, processing duration, presentation delay), which decides what kind of fix is even possible The analysis cites only numbers it read from your data, and every table states its slice and date window. Thin segments lower its confidence, never their importance, and it says which finding has lower confidence and why. So you can verify it in the technical dashboard, share it, or disagree with it. ## Where to find it AI analysis is live today for every RUMvision domain. No setup needed. 1. **Alerts:** go to **Workflow → Alert history** and click **Analyse this issue with AI** on any alert in the last 90 days. 2. **Health checks:** open **Health check**, expand a check and click **Analyse this issue with AI** on any open or recently closed issue. 3. Read the analysis, act on it, and watch the metric recover in the technical dashboard linked next to it. If you don't have alerts set up yet, now is a good moment: **Workflow → Alerts** lets you define thresholds per metric, device and page group in a couple of minutes. The more precise the alert, the more precise the analysis. We'd love to hear what the analysis gets right and where it falls short. Hit **Support** in the top right or reply to this post. Every analysis you run helps us make the next one better.