Monitor
Continue observing status signals; no automatic investigative Incident.
ServiceNow case study · Version 1 completed · November 2026
Outage Shield
Making vendor outage signals actionable in ServiceNow. A scoped Personal Developer Instance application that maps third-party status information to internal Service Offerings, applies preliminary business-risk rules and supports governed ITSM response.
Controlled automation:
Outage Shield includes a configurable safety switch that separates
live vendor monitoring from automated ITSM actions. Incident creation,
priority escalation and Major Incident proposals were
validated through controlled testing.
01 / The challenge
Outage alerts need business context.
GitHub and Cloudflare publish technical status information about their services. That information does not, by itself, tell an organisation which internal services might be affected or whether an investigative Incident should be created.
Outage Shield connects vendor-reported components to ServiceNow Service Offerings, applies a preliminary risk assessment and guides a proportionate response while preserving human control over Major Incident declaration.
Why I built it
Having spent over 20 years running technology-led businesses, I've seen how technical problems quickly become operational problems. What interested me about ServiceNow was the opportunity to connect technology, business processes and practical decision-making.
With Outage Shield, I wanted to go beyond simply retrieving API data and creating Incidents. The interesting challenge was determining which services might actually be affected, when an Incident was justified and how to automate the response without losing human oversight.
My responsibilities
Business and functional requirements, As-Is/To-Be process analysis, user stories, solution design, scoped ServiceNow configuration, REST integration, scripting and functional validation.
02 / Solution design
From vendor API to service-aware response
A structured process converts external incident data into internal service context and an auditable action.
-
Poll vendor status APIs
Scheduled requests retrieve GitHub and Cloudflare data and process the returned JSON.
-
Correlate components to Service Offerings
Mapping records identify potentially affected internal offerings instead of treating all vendor components equally.
-
Assess preliminary business risk
Vendor severity is considered alongside Service Offering criticality, with uncertain or invalid evidence routed to review.
-
Apply native ITSM governance
Controlled tests validate investigative Incident creation, escalation on an existing record and a proposal—not automatic declaration—of a Major Incident.
-
Prepare subscriber communications
When possible offering impact starts or clears, events generate queued notifications for eligible subscribers; unchanged conditions suppress duplicate event batches.
Design decisions and trade-offs
I wanted Outage Shield to use ServiceNow's existing capabilities wherever practical, rather than build custom functionality unnecessarily.
- Use the standard priority matrix. I used ServiceNow's Impact/Urgency matrix to calculate Incident priority instead of assigning priority numbers directly in custom code.
- Reuse Incidents rather than create duplicates. Repeated vendor updates should not generate a new Incident every five minutes. I designed the application around one primary Incident per vendor outage.
- Keep Major Incident declaration under human control. A severe vendor outage can justify a Major Incident proposal, but it doesn't prove the organisation is experiencing a Major Incident. Declaration remains a human decision.
- Handle uncertainty rather than assume impact. Missing service mappings, conflicting vendor information and invalid API responses require safeguards. I chose to flag uncertain situations for review instead of automatically escalating them.
03 / Decision policy
Proportionate escalation, with human oversight
Preliminary risk drives the response. Incident priority is calculated using ServiceNow's configured Impact/Urgency matrix rather than directly equating risk labels to priority numbers.
Investigate · P3 target
Create a standard investigative Incident for potential impact.
Escalate · P2 target
Create or increase priority on the existing primary Incident.
Propose Major Incident
Create an investigative Incident and submit a native proposal for human assessment. Never auto-declare.
04 / Screenshots & validation
Evidence, not just a feature list
Each screenshot is from the ServiceNow Personal Developer Instance. Select any image to inspect its full-resolution original.
Evidence 01 · Configuration
Component-to-service mapping
Four active operational mappings connect selected GitHub and Cloudflare components to Source Code Management and Website Availability offerings.
View full screenshot ↗
Evidence 02a · Native ITSM
Investigative Incident
A controlled test creates a standard Incident linked to Source Code Management, with impact described as potential rather than confirmed.
View full screenshot ↗
Evidence 02b · Audit trail
P3 → P2 escalation
INC0010007 moves from P3 to P2 on the same record as urgency rises. Additional controlled output verified primary-Incident reuse.
View full screenshot ↗
Evidence 03a · Governance
Very High risk response
An investigative P2 Incident records a critical GitHub report and explains that internal impact is still subject to investigation.
View full screenshot ↗
Evidence 03b · Native ITSM
Major Incident proposed
The native Major Incident state is Proposed, retaining human assessment and avoiding automatic declaration.
View full screenshot ↗
Evidence 04 · Negative-path testing
4 / 4 safeguards passed
Unmapped, conflicting, missing and invalid component data were handled without confident automatic impact classification or escalation.
View full screenshot ↗
Evidence 05 · Integration
Recurring vendor polling
Repeated success logs for both API sources are consistent with five-minute scheduled polling. The scheduler was also observed during testing.
View full screenshot ↗
Evidence 06 · Communications
Subscriber notification events
Initial-impact and impact-cleared emails were generated and queued for two test subscribers. Ready state does not prove external delivery.
View full screenshot ↗05 / Testing and validation
Version 1 validation results
Demonstrated in Version 1
- Live REST polling and processing of GitHub and Cloudflare status data.
- Vendor component-to-Service Offering mapping and risk context.
- Controlled Incident creation, primary-Incident reuse and P3 → P2 escalation.
- Native Major Incident candidate proposal for human review.
- Four fail-safe test paths passed.
- Subscriber event generation and queued outbound email records.
Testing scope
Testing was conducted in a ServiceNow Personal Developer Instance. Live vendor monitoring was tested against the real GitHub and Cloudflare APIs; Incident automation was validated separately using controlled test payloads.
Source: Outage Shield Version 1 Test Evidence Report, evidence captured 03 November 2026.
06 / Source & next steps
Explore the implementation
The Outage Shield source code and supporting test evidence are available for review on GitHub and in this case study.
For the next iteration, I'd focus on HTTP timeout and retry handling, expanding automated regression tests and validating the complete Incident lifecycle under unattended operation.