Xurrent IMR - Q2 2026 Product Updates
Note: We're just getting started with Q2. This post is a living document, and we'll keep adding new updates right here until the quarter ends on June 30th.
ServiceNow Integration: More Robust Now
If you've ever tried to scale our old ServiceNow integration across more than a handful of services, you know the pain. It needed a Configuration Item to route alerts, and every service needed its own manual setup. For teams managing hundreds of services, it just didn't work.
We heard about this. A lot. So we rebuilt it.
No CI dependency. Map any ServiceNow field to your IMR services. Configuration Item, Assignment Group, Service Offering, or a custom field your team already uses. Pick whatever makes sense for how your org runs.
Auto-mapping that actually works. Name Match maps services automatically by name. Custom Match lets you define exact ServiceNow value to IMR service mappings when you need full control. No more spreadsheets, no more manual one-by-ones.
One global template. Configure status, urgency, priority mappings, note syncing, and mandatory fields once. It applies across all your services automatically. Set it and forget it.
Bulk setup. Create integrations across all your services in a single step. What used to take an afternoon now takes minutes.
If you're running ServiceNow and have been waiting to roll out IMR more broadly, this is the unblock.
Xurrent IMR MCP Server is Live
You can now connect Xurrent IMR to Claude and ask questions about your incident data in plain English. No tab switching, no SQL, no logging in.
Ask things like:
- "Show me all critical incidents from the last month"
- "Who is on call for the SRE team right now?"
- "Walk me through the timeline of incident #75"
Claude connects directly to your IMR account through an MCP server and returns real data: on-call schedules, incident lists, timelines, and more. The kind of context you usually have to dig through three tools to find.
This is read-only today. No changes, no risk. Just faster access to the context your team needs during an incident, in the place where a lot of you already do your thinking.
Setup takes under 5 minutes.
Noise Reduction is Now Available
Alert fatigue is one of the most common reasons on-call engineers burn out. Noise Reduction fixes that by grouping related alerts into a single incident, so your team isn't paged repeatedly for the same underlying issue.
Two ways to correlate alerts, depending on what fits your stack.
Time-based Correlation. Group all alerts that arrive within a set time window (1 to 20 minutes) for a particular service into a single incident. Simple, predictable, easy to reason about.
Content-based Correlation. Group alerts based on matching payload fields. You choose:
- Matching logic: correlate if any or all fields match
- Fields: Incident Title, Incident Summary, Integration, or a Custom JSON field (for example, host_id)
- Time window: 1 to 20 minutes
A real example
A cluster goes down. Within seconds, your monitoring fires a memory alert, a CPU alert, a disk I/O alert, and a few more. All symptoms of the same root cause.
Without Noise Reduction, each of these creates a separate incident and wakes up your on-call engineer multiple times. With Noise Reduction, all of them roll up into a single incident. Your team gets paged once and has full context in one place. The engineer wakes up to "the cluster is down" instead of "five things are on fire and I have to figure out which is which."
[Read the full documentation →]
Coming soon
We have two more pieces in the pipeline that will join Noise Reduction shortly:
- AI Correlation: Machine learning that automatically groups related alerts based on patterns in your data. No rules to write.
- Auto Pause Transient Alerts: Automatic suppression of short-lived, self-resolving alerts that would otherwise create unnecessary incidents. The alerts that always resolve themselves before anyone reads them.
Click Get Beta Access on the Noise Reduction tab if you want early access to these.
New Workflow Actions: Jira and Slack
You can now add Jira and Slack as action steps in your Workflows, so the right people and tools are looped in automatically when an incident event fires. No more "did anyone open the Jira ticket?" five minutes into an incident.
Create Jira Ticket. Opens a Jira issue with your pre-configured project, issue type, and custom fields. Triggered automatically when your conditions are met. No manual ticket creation after every incident.
Send Slack Message. Send a message to an existing Slack channel or create a new one on the fly. Two ways to use it:
- Custom message: write your own message with dynamic variables pulled from the incident. For example: "🚨 This P0 incident has been open for 1 hour and is causing customer impact. {On-call Agent}, can you resolve this at the soonest?"
- Incident details card: send a structured card with incident details automatically populated. Useful for piping all P0s into a single war-room channel so stakeholders have one place to track what's open.
Both actions plug into the same Workflow trigger system we shipped in Q1. Pick a trigger (incident created, status updated, urgency changed, etc.), set your conditions, and the Jira ticket or Slack message fires the moment your conditions are met.