ServiceNow ITOM Health Check

An ITOM health check is mostly a judgement about whether the event stream can be trusted, and that depends on Discovery freshness as much as on correlation rules. This page covers the Discovery, Event Management and Service Mapping assessments, recommendations and roadmap, baseline metrics, continuity and integration checks, capacity, the evidence to collect before the review meets anyone, an ordered review sequence, the signs that should be flagged immediately, and when a health check will not change much.

Discovery Module Assessment

We evaluate your discovery process: are discovery appliances configured and running effectively, are discovered assets being correctly categorized, is discovery keeping your CMDB current as infrastructure changes. We assess data quality—are discovered records accurate and complete, are duplicates being identified and merged, is the federation strategy working if you have multiple CMDB sources. We identify optimization opportunities: untapped asset types that could be discovered, enrichment opportunities, integration improvements.

Event Management Assessment

We review event ingestion: are all expected monitoring sources connected and sending events, is ingest latency acceptable, are no events being dropped. We assess correlation: are similar events from different sources being intelligently grouped, are spurious events being suppressed, is alert volume manageable without losing critical events. We review escalation: are events reaching the right teams, are escalation paths effective, are SLA timers working. We identify optimization opportunities for correlation rules and suppression strategies.

Service Mapping and Dependencies

We assess whether service maps reflect your actual business services and dependencies, whether mapping is comprehensive or contains gaps, and whether maps stay current as infrastructure changes. We validate that incident and event correlation uses service maps to provide business context to responders.

Optimization Recommendations

The health check identifies optimization opportunities specific to your ITOM deployment. Common recommendations include improving discovery efficiency by tuning discovery patterns to reduce redundancy, enriching discovered data with additional asset attributes for better visibility, updating correlation rules to reduce noise and improve event quality, optimizing MID server configuration for better performance, and improving integration with monitoring tools. Each recommendation includes effort estimates and expected value.

Roadmap Development

The health check produces a prioritized roadmap for ITOM improvements. Quick wins—improvements requiring minimal effort with immediate value—are recommended first. Larger initiatives requiring configuration changes, process redesign, or staffing adjustment are planned in phases. The roadmap helps you sequence investments and manage expectations about effort required.

Validation and Baseline Metrics

The health check establishes baseline metrics for your ITOM system: discovery coverage and accuracy, event ingestion rate and quality, correlation effectiveness, escalation timeliness, and incident context quality. These baselines provide comparison points to measure improvement after implementing recommendations. Regular re-assessment—quarterly or annually—shows progress and identifies new optimization opportunities as infrastructure evolves. Tracking these metrics over time demonstrates value delivered and helps justify ongoing investment in ITOM operations and enhancements. Benchmarking against industry standards provides additional context for evaluating your deployment’s maturity and comparing progress against peers.

Disaster Recovery and Business Continuity

ITOM systems often support critical business operations. The health check includes assessment of disaster recovery and business continuity capabilities. Can you recover Event Management if it fails? Do you have backups of configuration? Can you quickly failover to a properly configured backup system? These questions ensure your ITOM environment can survive critical failures without disrupting business operations. Recommendations might include backup strategies, redundancy, or recovery procedures.

Integration Monitoring and Health Checks

Event Management integrates with many monitoring tools and data sources. The health check reviews these integrations to confirm they are healthy. Data ingest rates should be stable; sudden drops might indicate an integration failure. Connection status should be monitored. Authentication credentials should be updated before they expire. These integration health checks prevent silent failures where data stops flowing without anyone noticing until it causes problems.

Capacity Planning and Scalability

As infrastructure grows, event volume may increase. The health check reviews event ingestion rates and system capacity. If event volume is growing, capacity planning ensures you add resources before the system becomes overloaded and performance degrades. Scaling might involve tuning configurations to be more efficient, adding computing resources, or optimizing data retention policies to manage database growth.

Judging whether the event stream can be trusted

This section is for the monitoring lead who suspects that ITOM is producing either too much noise or too little signal, and needs to know which. A health check on ITOM is mostly a check on trust. Engineers often stop reading alerts that have been wrong before, and once that happens a working monitoring setup is effectively switched off. The useful question is therefore not whether events arrive, but whether the people on call believe what arrives.

Two things can be true at once: the platform shows a large number of open events, and the on-call team has learned to ignore most of them. The review should measure both the volume and the response, because a high volume that is acted on is a different problem from a high volume that is ignored.

Evidence worth collecting before the review meets anyone

Evidence	What it reveals	Limit to remember
Open events by age	Events that never cleared, which can mean the fault was fixed without the source being told	Old events can also be real, long-running faults that nobody owns
Events that open and close repeatedly	Flapping thresholds, often on a metric near its limit	Flapping can be genuine on an unstable service
Events with no configuration item	Gaps in discovery or a mismatch between naming in the monitoring tool and the CMDB	A missing link can be deliberate for devices outside the scope
Incidents raised from events, and how many were closed as not needed	Whether the incident policy is generating work nobody needs	Closure reasons are only as good as the people who write them
Discovery last-run results	Whether the infrastructure picture is fresh enough to route alerts	A successful run can still miss devices behind a blocked credential

An ordered review sequence

1. Take a two-week sample of events and sort them by source, severity and whether they led to an action.
2. Pick the five sources that produce the most events with no action, and examine whether their thresholds or their scope is wrong.
3. Check that the configuration items those events attach to exist, are current and belong to a service with an owner.
4. Interview the people who take the calls and ask which alerts they have learned to ignore, and why.
5. Write a finding for each source: tune, re-scope, suppress with an expiry, or retire.

Suppression deserves a note of caution. A suppression rule with no expiry date becomes a permanent blind spot. Require every suppression to name an owner and a review date, and treat an expired suppression as a finding in the next review.

Discovery freshness and why it matters to alerts

Alert routing depends on the configuration picture being current. If discovery has not refreshed a device, an alert about that device may attach to an old record, reach the wrong group or be dropped. The health check should confirm the discovery schedule for each class of device, the timestamp of the most recent successful run and the count of devices whose record has not changed in a long time. The schedule itself is explained in the guide on discovery schedules, and the matching of records is covered in the guide on the identification and reconciliation engine.

Signs the review should flag immediately

• Engineers have a standing rule to ignore one whole source of events.
• Critical events are acknowledged in bulk without any change in the affected service.
• Incidents raised from events are routinely reassigned to a team that does not own the affected item.

Each of these describes a monitoring design that has stopped informing decisions. They need prompt action, not a place in a roadmap, and they often indicate that the baseline the platform was built against is no longer true. Background on what an operational baseline describes is in the guide on ITOM operational baselines.

When a health check will not change much

A small estate with one monitoring tool and a team that reads every alert does not need a formal review. A short sample and a conversation with the on-call lead will do. Skip the review also when the monitoring tool itself is being replaced, because the findings will apply to a system that is about to go.

Questions about ITOM health checks

How much alert history is enough to judge a source?

Enough to include the normal rhythm of the service, which usually means at least one full working cycle and any weekly batch activity. A source judged on a quiet week will look better than it is.

Should a health check change alert thresholds directly?

It should recommend changes and let the owner of the source make them. Thresholds set by someone outside the team that receives the alerts tend to be reverted, and the reason for the change is lost.

How do we know if a missing configuration item is a problem?

Check whether the device is in the agreed discovery scope and whether it supports a business service. A device outside scope with no alerts is not a gap. A device inside scope that generates alerts with no record is a gap that needs a fix.

What should the outcome of the review look like?

A ranked list of sources with one decision each, a named owner for each decision and a date to revisit. A report without owners and dates will be read once and not acted on.

Next step for an event stream nobody trusts

Where the review leads to tuning work, the page on ITOM optimization covers what an ITOM optimization engagement reviews.

What an ITOM health check hands back, and what it needs from you

An ITOM health check hands back three things: a written judgement on whether your event stream, discovery data and service maps can be trusted, a ranked list of fixes with effort and expected value beside each, and baseline measures you can repeat later to see whether anything improved. It is a review of a deployment you already run, not a new implementation.

People searching for ITOM health sometimes mean the monitoring side of ITOM itself, the part that deals with events, metrics and logs. This page is about reviewing that side and the Discovery and CMDB data it relies on. If you want the review to cover the whole platform, the wider ServiceNow health check and assessment is the better starting point.

What you need to provide

• Read access to the instance for a named reviewer, set up through your own identity process.
• A list of the monitoring sources that are supposed to be sending events, with an owner for each.
• A sample of recent incidents that began as events, including ones that were closed as not needed.
• Someone who can explain why a few unusual rules exist. Every long-running instance has them, and the reason is rarely written down.

What changes the outcome

Two situations decide how much a review finds. Where discovery has not run cleanly for a long time, most alert problems trace back to missing or stale records, so the first recommendations will concern Discovery rather than rules. Where the data is sound but people still ignore alerts, the findings centre on correlation, ownership and thresholds in Event Management.

A review should also say plainly when little needs to change. If you are weighing it against a platform-wide audit, the health checks and audits page describes how the two relate.