Troubleshooting ServiceNow MID Server: A Practical Guide

This page helps a ServiceNow administrator work out why a MID Server has stopped, slowed down or failed its integrations and discovery scans. It starts from the symptom, then checks the host, the logs and the target system.

Symptom-Led Diagnosis Approach

MID Server issues manifest in different ways: it does not start, integrations using it fail, discovery hangs, or performance is degraded. Each symptom points to different causes. Start by identifying exactly what is broken.

Symptom: MID Server is not starting. Probable causes: configuration error, insufficient resources, connectivity issue. Check logs and startup details.

Symptom: Integration using MID Server times out. Probable causes: MID Server too slow, external system not responding, network connectivity issue. Check MID Server performance and external system status.

Symptom: Discovery scans hang or fail. Probable causes: MID Server crashed during scan, database not responding to queries, network issue during scan. Check MID Server health during scan.

Where to Look in ServiceNow

Navigate to MID Server administration in ServiceNow. Check MID Server list and status. Look for red flags: status not “Up”, last heartbeat older than the expected interval, error logs with recent errors.

Check MID Server logs. Navigate to each MID Server record and review recent logs. Look for errors that indicate what is broken: OutOfMemory errors indicate it needs more RAM, connection timeouts indicate network or external system issues, authentication failures indicate credential problems.

Check integration execution logs. If an integration using MID Server is failing, check the integration record for execution history. Review what it tried to do and where it failed.

Check MID Server communication logs. These show what ServiceNow and MID Server exchange. If communication is breaking down, logs will show the last successful heartbeat and any failed calls after that.

Common Causes and Fixes

Cause 1: MID Server ran out of memory. Symptoms: process crashes, logs show OutOfMemory errors. Fix: increase memory allocation to MID Server JVM. This usually requires infrastructure team to increase VM memory, then restart MID Server. If increasing memory does not help, investigate what is consuming memory (memory leak in integration code).

Cause 2: Credentials expired or changed. Symptoms: integrations start failing with authentication errors. Fix: update credentials in ServiceNow vault and restart MID Server processes using those credentials. Common for database discovery when password changes are not communicated to ServiceNow team.

Cause 3: External system not responding. Symptoms: integrations timeout or return errors. Fix: check external system status. Is it down, restarting, or slow? Once it recovers, integrations usually resume automatically. If external system is up and still timing out, investigate network connectivity or firewall rules.

Cause 4: Network connectivity broken. Symptoms: all integrations using MID Server fail simultaneously. Fix: check network connectivity from MID Server host. Ping external systems, check firewall logs, verify VPN connection. Work with network team if needed.

Cause 5: Discovery scan still running from last time. Symptoms: new discovery scan will not start, MID Server appears hung. Fix: kill the running discovery process in MID Server logs and retry. This usually happens if previous scan was killed abruptly without cleanup.

Performance Troubleshooting

When MID Server is slow, identify which operation is slow. Is discovery slow (scanning large network takes time)? Are integrations slow (API calls take long time)? Are MID Server processes slow (high CPU or memory usage)? Each has different solutions.

Check MID Server CPU and memory utilisation. If CPU is high, MID Server is working hard. If memory is high and increasing, there may be a memory leak. Monitor these metrics while operations are running to correlate with slowness.

Check external system responsiveness. If integrations are slow, the external system may be slow. Verify that external system is responsive by testing connectivity directly from the MID Server host.

Reduce scan intensity. Discovery scans consume resources. If discovery is slow, adjust scan frequency (run less often) or scan size (scan fewer systems per scan) to reduce load.

Escalation Points

If MID Server logs show Java exceptions and you do not know what they mean, escalate to ServiceNow support with the exception details. They can help diagnose platform issues.

If network connectivity is broken and you have verified firewall rules are correct, work with network team to investigate. Check traceroute to the external system, check for packet loss, check for routing issues.

If external system is returning errors to MID Server, work with the system owner to understand the error. Some errors require external system configuration changes that only the owner can make.

Prevention and Monitoring

Monitor MID Server health proactively. Set up alerting for MID Server heartbeat failures, error log entries, high CPU or memory utilisation. Do not wait for users to report problems.

Keep MID Servers patched. ServiceNow releases updates to MID Server frequently. Stay current on patches to avoid bugs that cause crashes or performance issues.

Document workarounds and fixes. When you resolve an issue, document the cause and fix. This helps the next person who hits the same issue and prevents repeated firefighting.

Sorting intermittent failures from hard outages

The first decision in a MID Server incident is not which log to open. It is whether the failure is constant, intermittent, or began at a specific moment. A constant failure often points at identity, network or the host itself. An intermittent failure points at load, timing or a target that is sometimes slow. A failure that started at a precise time often has a change behind it, and the first task is to find that change before going deeper into the host. Teams that skip this step often spend hours on a healthy server because the fault sits in a firewall change made the previous afternoon.

Write the pattern down before you touch anything. Note when the failure first appeared, whether it affects one integration or all of them, whether it recurs on a schedule, and which member of the cluster is involved. That short note is the most useful thing you can hand to a network engineer or a vendor, and it saves a round of questions.

Triage by pattern

The table gives a first place to look for each pattern. It is a starting point for investigation, not a diagnosis, and the evidence column tells you what would confirm or rule out the first guess.

Ordered procedure for an escalation-ready investigation

1. Record the observed pattern, the start time, the affected integrations and the affected cluster members.
2. Check for a change in the same window, on the host, the network, the target and the instance.
3. Read the most recent job history entries for one failing job, and copy the exact error text rather than a summary.
4. Check the state of the host’s service and its recent log entries for the same window.
5. Test the target from the host using the same protocol and credential the job uses.
6. If the cause is still unclear, package the pattern note, the error text, the change list and the test result for the escalation owner.

What a restart does and does not prove

A restart can clear a stuck process, but it does not explain why the process got stuck. If the failure returns, the restart was a workaround, and the investigation should continue from the evidence already collected.

Why target-side logs matter

A job can report a timeout that began on the target side, such as a locked table or a slow query. Ask the target owner for their own log for the same window before blaming the network or the host.

When to stop investigating and escalate

Escalate once the pattern is clear and the evidence points beyond what the team can change, for example a platform defect or a target system fault. Continuing alone past that point rarely improves the outcome.

Handling a failure during a maintenance freeze

Capture the evidence during the freeze, but defer configuration changes until the freeze lifts unless the outage is business-critical. A rushed change during a freeze often causes a second incident.

Prevention that shortens the next investigation

Much of the time spent on an incident goes to finding the change, not to fixing the fault. Keep a change calendar that covers the hosts, the network and the targets, and link each MID Server incident to it. Read the common mistakes with MID Servers for habits that can cause these patterns, and use the testing checklist to check how a change should be tested before it reaches production. Ongoing watch of the host and its jobs is covered in the proactive monitoring and maintenance service.

The question of who should be alerted when a pattern repeats is an ownership question as much as a technical one. The note on integration monitoring ownership sets out why the owner of the integration, not the host team, is often the right first contact.

Bring the pattern notes and the change calendar for the last few weeks; those two records often show the cause faster than another night of log reading.

Questions about MID Server troubleshooting

Should the host be rebuilt when it misbehaves?

Rebuilding is a last resort. It removes the evidence you need to find the cause, and it can reintroduce an old fault if the image was the problem.

How much log history should be kept?

Keep enough to cover the longest normal gap between a change and its first visible symptom, plus the change records themselves. Retention set by disk size alone often loses the window you need.

Why does a failure only appear for some members of the cluster?

Often because the members differ in patch level, network path or credential state. Compare them directly rather than assuming they are identical.