- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Did I trick you into thinking that I was a baseball fan? Sorry to disappoint, but I am not. The Blue Jays losing was unfortunate though (I think I have to say that because I'm Canadian?).
Like any new year, 2026 started off a bit slow, but quickly ramped up and now I'm here to talk to you about what I thought were the highlights of the Q1'26 store & Australia family release!
With the Q1 release and many other things that are coming out this year (hint hint), we understand that nobody gets AIOps right on the first try. That's not a criticism of anyone. It's just honest. Modern IT environments are complex, alert pipelines are noisy, HLA setup has historically required deep expertise, and CI binding was a pass or failure scenario. The cost of those imperfect conditions isn't abstract — it shows up as longer triage times, more manual investigation, and operators spending their incident response window assembling context instead of acting on it. So we're building AI directly into our configuration experiences, and some fallback opportunities - second or third times a charm!
Three chances to get it right: CI Binding Fallback
CI binding fallback gives operators three attempts — not one — to successfully associate an alert with a configuration item. If the first match fails, you now have two additional options: explicitly define which alert field maps to which CI attribute, and bind alerts to non-host CIs without clearing the node field.
That last part matters more than it sounds. Clearing the node has always been one of those confusing steps that quietly stops teams from moving forward with event management adoption. When alerts aren't bound to CIs, the downstream consequences compound: impact analysis is incomplete, alert grouping is less accurate, and root cause investigation takes longer because the relationships between alerts and the infrastructure they're describing aren't properly established.
Smarter grouping, fewer noise complaints
The same philosophy runs through the alert grouping enhancements this quarter. Mixed alert group support now lets you combine HLA alerts, tag-based alerts, and CMDB-based alerts into a single grouping automation, easily configured in Alert Automation. With the new unified correlation strategy, alert and incident triage is accelerated and silos between related alert groups are eliminated.
Advanced alert grouping conditions take it further. You can define minimum thresholds so a group doesn't form unless a certain number of alerts match, and seed alert criteria that require at least one alert to meet a specific condition before the group is created at all. The practical outcome is that alert groups represent actual operational events worth responding to — not artifacts of correlation logic running on marginal signals. Operators spend less time dismissing noise and more time on the issues that matter.
Tying it together: you can now configure alert grouping automations conversationally through Now Assist. Describe what you want — group by service and log properties, minimum three alerts, at least one must be critical — and the agent builds the automation. Refine it in conversation, or open it directly in Alert Automation to simulate before activating. Teams that previously needed deep platform expertise to configure grouping correctly can now get to a well-tuned automation significantly faster, which means getting value from event management sooner rather than treating configuration as a long-term project.
Agentic observability gets deeper context
Manage Alerts Autonomously has been in market since January, but the Q1 enhancements are worth pausing on. A new HLA hypothesizer skill evaluates whether an alert is proactive or reactive — and if proactive, surfaces likely failure scenarios if the alert isn't addressed, along with suggested next steps. What may have been obscure log anomaly alerts, become actionable and opportunities for proactive remediation.
Agentic observability also now supports Dynatrace and Splunk AI agent Model Context Protocol integrations. What MCP enables practically is the ability to query live production systems and chain multiple tools together in ways the previous API integration couldn't. Logs, metrics, traces, affected users — all of it pulled into the alert summary without the operator switching tabs. And if you want to query for additional information, you can interact with the external agents in a conversational experience through Now Assist. The time that used to go toward tool switching goes instead toward actually resolving the issues.
HLA setup, but with AI recommendations
Health Log Analytics configuration can be complicated to those who are seeing the logs for the first time. When HLA isn't configured correctly, log anomaly detection will encounter errors, which means a whole category of proactive signals — the ones that could catch issues before they become alerts — will never reach operators.
This quarter, AI recommendations are embedded directly into the HLA setup experience in Service Operations Workspace. The system learns from your actual log data — up to 24 hours of it — and recommends which field to use for service instance identification, which for component, and how to map source type. The recommendations are clearly marked and generated from your data, not generic defaults. You're not required to take them, but they're right there, and after 10k+ logs are analyzed to generate them I think they are probably decent.
One thing worth calling out: automated source type mapping using the new identification algorithm does not require Now Assist. It works independently, which matters for teams earlier in their AI journey. AI-suggested classifications and labels for log properties are also now part of the experience. The combined effect is that teams can complete a setup that previously required expert guidance — or a long trial-and-error cycle — in a fraction of the time, and start seeing anomaly detection results sooner.
The through-line
All of these capabilities are versions of the same idea. IT environments don't need products that assume ideal conditions. They need products that work when conditions aren't ideal — that surface better information faster, build in fallbacks, reduce the expertise barrier to getting configured correctly, and give operators the context they need to act rather than investigate.
Shorter triage. Faster time to value. Fewer incidents that escalate because the signals were there but nobody could act on them quickly enough. That's what this quarter is building toward. Three attempts, not one — and a platform that keeps getting better at making the first attempt more likely to succeed.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
