I want to share our implementation of automated alert routing from Cumulocity to ServiceNow that dramatically reduced our incident response times. Before this integration, our operations team was manually reviewing alerts in Cumulocity and creating ServiceNow tickets for actionable incidents, which created a 2-4 hour delay in incident response.
We built a custom microservice using the Cumulocity Microservice SDK that subscribes to real-time alert events, applies intelligent filtering and enrichment logic, and automatically creates corresponding incidents in ServiceNow. The microservice processes alerts within seconds of creation and includes device context, historical data, and severity mapping.
The implementation uses the Microservice SDK’s event listening capabilities and ServiceNow’s REST API for incident creation. We’ve been running this in production for three months across 1,500 industrial IoT devices, and it’s reduced our average incident response time from 3.5 hours to 25 minutes. I’d be happy to share implementation details and lessons learned for anyone considering similar integrations.
What about error handling and resilience? If ServiceNow is temporarily unavailable, does the microservice queue alerts and retry, or do you risk losing critical notifications? Also, how do you handle the microservice’s own monitoring - if the integration microservice fails, how do you detect and recover?
Great question. Our filtering logic uses a combination of alert severity, device criticality, and business impact scoring. We only route CRITICAL and MAJOR alerts to ServiceNow automatically. MINOR alerts are aggregated and sent as daily summaries unless they persist for more than 4 hours, which elevates them to MAJOR. We also maintain a device criticality database that assigns business impact scores - alerts from high-impact devices get priority routing. The microservice evaluates these rules in real-time:
if (alert.getSeverity() >= Severity.MAJOR &&
deviceCriticality.getScore(alert.getSource()) >= 7) {
createServiceNowIncident(alert);
}
This filtering reduced our ServiceNow ticket volume by 85% compared to routing all alerts, while ensuring no critical issues are missed.
This sounds like exactly what we need. Can you share more details about the filtering logic? We’re concerned about alert fatigue - if we automatically create ServiceNow tickets for every Cumulocity alert, we’ll overwhelm our service desk. How do you determine which alerts warrant ServiceNow incident creation versus which ones should be handled differently?
Yes, bidirectional synchronization was critical for us. The microservice maintains a mapping table between Cumulocity alert IDs and ServiceNow incident numbers. When an alert is cleared in Cumulocity, the microservice automatically resolves the corresponding ServiceNow incident with resolution notes. Conversely, when a ServiceNow incident is resolved, we update the Cumulocity alert status. This prevents orphaned tickets and ensures both systems reflect the current state. We use ServiceNow’s REST API to update incidents and Cumulocity’s Alarm API for status updates. The mapping table is stored in the microservice’s persistent storage using the platform’s database services.