ServiceNow ITOM Managed Support

ITOM managed support is the ongoing care of infrastructure monitoring once it is running. It keeps monitoring configuration accurate, tunes alerts so operators trust them, maintains runbooks, and sets up the on-call path and the hand-off into ITSM incidents. This page helps an operations manager judge whether the arrangement can handle an event storm.

Managed support for ITOM is judged in the first minutes of an event storm: whether events are classified so the response path is obvious and whether the on-call rota is workable. This page covers monitoring configuration and drift, alert tuning and false positives, runbook effectiveness, capacity and threshold forecasting, on-call escalation, compliance tracking, the hand-off into ITSM incidents, what to review after a storm, and when managed support should not take the first call.

Infrastructure Monitoring Configuration and Maintenance

ITOM monitoring configuration is complex and requires ongoing maintenance. Monitoring agents must be deployed and updated on servers. Discovery profiles must be tuned to find infrastructure correctly. Monitoring credentials must stay current as systems change. Baseline metrics must be updated as infrastructure grows. We maintain this configuration: deploying new monitoring agents when new servers come online, updating discovery profiles when infrastructure changes, refreshing credentials quarterly, updating baselines as capacity grows. Most organizations discover they’ve deployed monitoring but it slowly drifts out of accuracy: new servers aren’t being discovered, old servers are still being monitored even though decommissioned, baselines are years out of date. Managed support prevents drift by maintaining configuration continuously.

Alert Tuning and False Positive Reduction

Alert configuration is often set during initial deployment and rarely tuned. Thresholds are too high (missing real problems) or too low (creating false positives that operators ignore). Review alert configuration by analyzing alert history, measuring false positive rate, and adjusting thresholds based on infrastructure behavior. A disk alert set to trigger at a fixed threshold might fire constantly on development servers (normal), but miss real problems on production servers (need tighter threshold). Tune dynamically: use different thresholds for production and non-production, use growth-based thresholds (alert when disk grows significantly in short time), use time-of-day rules (different thresholds during backup windows). Proper alert tuning significantly reduces false positives, making alerts actually trusted by operators.

Runbook Review and Automation Effectiveness

Runbooks automate remediation: when disk fills up, automatically archive old logs to free space. When database connection pool exhausts, automatically increase pool size. Runbooks are often written during implementation and rarely tested after. We review existing runbooks: testing them against current infrastructure, validating they still work after system changes, measuring their effectiveness (what percentage of triggered runbooks actually resolve issues). We identify runbooks that fail or need updates: a runbook to manage storage might fail because storage is now managed by different team, or thresholds for triggering runbook have changed. We also identify opportunities for new runbooks: manual tasks that resolve 80 of issues could be automated. Runbook improvements typically increase automation success rate and reduce mean time to resolution for common issues.

Capacity Planning and Threshold Forecasting

ITOM generates historical data showing infrastructure growth. This enables forecasting: based on historical trends, when will you run out of disk space, when will CPU saturation reach limits, when will network bandwidth need expansion. We analyze trends: CPU growth rate, disk growth rate, memory utilization patterns. We forecast: if disk use has grown steadily, you can estimate when current storage capacity will run out, provided growth continues. We communicate forecasts to IT leadership: here’s when storage expansion is needed, here’s when database server replacement is required. Forecasting enables proactive expansion: you can procure and deploy capacity before problems occur rather than emergency purchases when systems are full.

On-Call Escalation and Incident Response

Critical infrastructure problems need immediate response. We establish escalation paths: critical alerts automatically page on-call engineer, escalate to senior engineer if unacknowledged, escalate to manager if unresolved. During support hours we handle escalations; outside support hours, alerts route to customer’s on-call team. We maintain on-call documentation: runbooks for common issues so responders know what to do, contact information for escalations, known workarounds for recurring problems. We also participate in incident post-mortems: after critical incidents, we review what happened, why monitoring didn’t catch it earlier, what changes prevent recurrence. Post-mortems often surface need for additional monitoring, better runbooks, or configuration changes.

Compliance and Change Tracking

Organizations sometimes need audit trails for compliance: what configuration changes were made when, who made them, why. ITOM change tracking supports this: all configuration changes are logged, approved through workflow if required, documented for audit. We maintain change practices: reviewing proposed monitoring changes for risk, testing changes before production deployment, documenting rationale for changes, maintaining change calendar so teams know when monitoring configuration is being updated. This governance prevents surprise monitoring changes and provides audit trail.

Integration with ITSM for Incident Creation

ITOM monitoring often triggers incidents in ITSM. We ensure this integration works smoothly: events from monitoring correctly create incidents, incident urgency reflects event severity, incidents include context (which server, what error) so resolution teams can diagnose quickly. We also tune incident creation: not every event should create incident; low-priority events should be consolidated. Some events should auto-escalate if unresolved after time. We maintain this integration over time: as ITSM configuration changes, integration configuration updates accordingly.

Handling an event storm during the first minutes

The reader is an operations manager who has to keep an on-call team functioning when one fault produces many events. An event storm is a common test of an ITOM support arrangement, and the first decisions made during it matter more than the tooling. The aim in the opening minutes is to find the one underlying cause, stop new work being generated by the same fault, and keep the people who are not affected out of the queue.

1. Group the events by source and by the configuration item they attach to, and look for the single item or shared dependency that most of them point to.
2. Check whether the events are correlated already. If not, the on-call engineer should work the largest group first rather than the most recent event.
3. Confirm that one incident represents the underlying fault, and that the others are linked to it rather than left as separate work.
4. Decide who is told. Affected service owners need one message, not one per event.
5. Record the time the storm started and the time the first event was attached to a cause. Those two times are the material for the review afterwards.

Classifying events so the response path is obvious

Support works faster when every event class has a response path that the on-call engineer can follow without asking. The classes below are a starting structure for discussion with the team that will use them.

Event class	Response path	Who acts	Stop condition
Service-affecting fault on a mapped service	Incident, linked to the service and its owner group	On-call engineer, then the service owner	Service is restored and the cause is recorded
Capacity warning with time to act	Task for the day team, not a page	Capacity owner	Threshold is no longer near, or capacity is added
Repeated transient fault on one item	Problem candidate once the repeat count is agreed	Problem manager	Root cause is found or the item is retired
Event with no configuration item	Triage queue for the discovery owner	Discovery or CMDB owner	Item is created, or the event is confirmed out of scope

The table is deliberately short. Teams that try to classify every event often end up with a classification nobody maintains. A few classes used every day are worth more than a long list reviewed once a year.

Keeping the on-call rota workable

An on-call rota often fails when the same person is paged for the same known fault every week. Track pages by cause rather than by event, and treat a repeated cause as a problem record rather than as routine work. The problem process is set out in the guide on problem records, and a documented workaround for a repeated fault belongs in the guide on known errors, so the next shift does not spend its night rediscovering it.

For the first-response habits that keep a shift steady, the guide on the first five minutes of incident triage covers designing the first five minutes of incident triage.

What to review after a storm

• How many events were created, how many became incidents, and how many of those were closed as duplicates.
• Which event source raised the first event, and whether that source had any warning before it.
• Whether the affected service owner received one clear message and when.
• Which rule, if any, should change so that the same storm produces fewer incidents next time.

Keep the review blameless and short. Its purpose is to change the rules that produced the storm, not to decide who should have noticed it sooner.

When managed support should not take the first call

Some events should go straight to the owning team without support triage, particularly where the owner has a specific runbook and a faster route to the fault. Managed support should not sit between an owner and a fault they can fix in minutes. The support arrangement should list these exceptions by name, so nobody on shift has to make that call under pressure.

Questions about ITOM managed support

How should a storm be communicated outside the operations team?

Through the same channel used for major incidents, with one update to affected owners and a short status line for anyone who asks. Repeated individual messages add to the load on the people who are fixing the fault.

Should every event be acknowledged by a person?

No. Events that clear on their own, or that the platform correlates into a parent incident, do not need an individual acknowledgement. Requiring one generates false work and hides the events that do need a person.

What if the on-call engineer cannot find the owner of an item?

Route the event to the discovery or CMDB owner as a triage item and note the gap. Holding the event until the owner is found delays the response, and guessing the owner sends the work to the wrong team.

Running on-call support with a clear path

The incident management and resolution page covers round-the-clock cover of that kind.