ServiceNow MID Server Explained

What a MID Server Is

A MID Server is a lightweight application that runs in your data center or on your network. It connects ServiceNow to resources it cannot reach directly: on-premises databases, private networks, legacy systems, and monitoring tools that do not have public internet access. The MID Server acts as a bridge, allowing ServiceNow to perform discovery, monitoring, and integration with resources behind your firewall.

Without a MID Server, ServiceNow has no way to reach internal systems. The cloud-based ServiceNow application cannot access databases in your data center or monitoring agents on your network. The MID Server solves this by running locally, accessing internal resources directly, and sending data securely back to ServiceNow.

Where MID Servers Fit in the Platform

MID Servers enable several key capabilities. Discovery uses MID Servers to scan your networks and databases for configuration items. Monitoring uses MID Servers to collect performance and availability data from systems on your network. Integration uses MID Servers to connect ServiceNow workflows to internal applications and databases. Without MID Servers, these capabilities only work for cloud systems or systems with public internet access.

Most organizations with mixed cloud and on-premises environments deploy one or more MID Servers. Small environments might use a single MID Server. Larger environments with multiple data centers deploy MID Servers in each location for performance and redundancy. MID Servers in the same location act as a cluster; if one fails, another handles the work.

A Worked Example

Your company runs an on-premises database that tracks your facility locations and assets. ServiceNow needs to include that data in your configuration management database. You deploy a MID Server in your data center. The MID Server has database connectivity and runs discovery scans against your on-premises database. It reads the facility and asset data and sends it to ServiceNow, where the data populates your CMDB.

Later, you want to monitor the health of your on-premises application servers. An application monitoring tool runs on your network. Again, ServiceNow cannot reach it directly. A MID Server in your data center connects to the monitoring tool, collects performance metrics, and sends them to ServiceNow. Your ServiceNow dashboards now show real-time performance data from systems you own and operate.

Your helpdesk wants to create incidents in ServiceNow when your on-premises monitoring tool detects problems. The MID Server enables this: it polls the monitoring tool for recent alerts and creates ServiceNow incidents automatically. The workflow loop is now closed: internal tools detect problems, ServiceNow creates incidents and routes them to your teams, and your teams resolve them in ServiceNow.

Security and Management Considerations

MID Servers use encrypted channels to communicate with ServiceNow, so data in transit is protected. Network configuration should restrict MID Server access to only the resources it needs: specific databases, monitoring tools, and applications. MID Servers should not have broad network access; they should operate with least-privilege access to minimize risk if a MID Server is compromised.

MID Servers run as installed software, not as a service in ServiceNow. You are responsible for updating the MID Server software, managing its performance, and monitoring its health. ServiceNow provides updates; you apply them to your MID Servers. A failed MID Server disrupts discovery and monitoring until it is restored. Most organizations run at least two MID Servers for redundancy.

Sizing and Best Practices

MID Server capacity depends on the volume of discovery scans, monitoring checks, and integrations running through it. A busy MID Server processing hundreds of discoveries and thousands of monitoring checks needs more processing power than one handling lighter loads. Monitor MID Server CPU and memory during normal operations; if they consistently run at high utilization, add additional MID Servers to share the load.

Place MID Servers in the same geographic region as the resources they manage. A MID Server in your US data center should not manage resources in your Asia data center; deploy a separate MID Server there. Geographic distribution keeps network latency low and isolates regional outages.

Deciding where a MID server belongs before buying the hardware

Placement is the decision that determines whether a MID server helps or hinders. A server placed close to the systems it manages has short, reliable connections and simple firewall rules. A server placed far away, behind a proxy that inspects traffic, depends on that proxy’s behavior for every discovery and integration call. The right location is the network segment that already contains the resources the server has to reach, rather than the central data center out of habit. Before choosing a host, list the targets it will touch, the protocols each target uses, and the firewall rules each one needs.

Placement	Strength	Risk to plan for
Same segment as the managed estate	Short paths and simple rules for discovery	The server becomes a high-value host, so its own patching and access need strict control
Central data center	One place to operate and monitor	Every remote target depends on the links between sites
Cloud network with private connectivity	Close to cloud workloads without exposing them	Routing and security group changes in the cloud can silently break reachability
Branch location	Local discovery where the branch network is isolated	Little local support, so failures can sit unnoticed

A checklist for standing up a MID server that will last

1. Name the owner of the host and the owner of the MID server application as two separate people, and write both names in your operations register. The integration monitoring guide covers assigning owners to failures.
2. Create a dedicated service account for the server, with the narrowest rights the target protocols need, and record which targets each credential can reach. The discovery credentials guide covers scoping that access.
3. Open only the outbound paths the server needs, and confirm the proxy policy, if any, allows the instance traffic without inspection that breaks the encrypted session.
4. Install the application, validate the connection to the instance, and run a test against one representative target from each protocol.
5. Set up monitoring on the host itself, covering disk, memory and the application process, and route the alert to the owner named in step one.
6. Add the server to the patch and certificate calendars, since expired certificates and out-of-date software are common reasons a working server stops.

Diagnosing a MID server that has gone quiet

A quiet MID server is harder to diagnose than a crashed one, because nothing in the platform announces the problem. Discovery runs seem to finish, integration jobs seem to complete, and the records simply stop changing. Start by checking whether the server is connected to the instance at all. Check the server’s status, then the application log on the host, then the host’s own resources and the network path to each target. Many stalls trace back to a changed proxy rule, an expired certificate, a credential that was rotated on the target, or a queue that filled because a single slow target held every worker. Work through those in order, and fix the cause before restarting anything, because a restart clears the evidence.

Sizing and clustering without guessing

Sizing a MID server is an exercise in identifying the busiest hour, not the average day. Discovery probes, monitoring polls and integration calls tend to bunch around the same times, such as overnight runs and the start of a business day. Measure the host during those peaks, watch the queue depth, and add capacity or a second server when the queue grows faster than it drains. A cluster is useful for both load and resilience, but only if the servers share the same credentials and the same reachability, and only if the platform is configured to distribute work across them. A second server that cannot reach a target is not a backup for that target.

When a MID server is not the right answer

If the systems you need to reach are all cloud services with public endpoints, a MID server adds an extra host to patch and monitor without solving a problem. Likewise, a team that needs to reach one application for one integration may be better served by a direct connection that the security team has reviewed. The MID server earns its place when many targets sit behind a boundary and need a common, managed path. For a single target, weigh the operating cost of another host against the risk of a broader firewall opening.

Questions to answer in the design review

• Which targets must the server reach, and which protocol does each one use?
• Who restarts the server at two in the morning, and do they have the access to do it?
• What happens to discovery and integrations if the server is down for a day?
• Where are the credentials stored, and who can read them on the host?

Frequently asked questions about MID servers

Can two MID servers in different sites share one credential?

They can, but a shared credential widens the blast radius of a leak and makes the target’s audit log harder to read. Prefer one credential per site or per purpose, and record which server uses it.

Why does discovery work from one MID server but not from its twin?

The twin usually sits on a different network segment, uses a different proxy path or has a stale certificate. Compare the routes, the proxy configuration and the certificate expiry dates on the two hosts before you assume the platform is at fault.

Does the MID server store data locally?

It holds data in transit and in its work queue, and it keeps its own logs. Treat the host as a system that holds sensitive material, and apply the same patching, access and backup thinking you would apply to any server that handles credentials.

How do we know a MID server is healthy without watching it all day?

Alert on the host’s resources, on the process being up, and on the queue growing for longer than a normal peak. Those three signals can catch many problems early.

Next step

If a MID server was set up quickly and now carries monitoring and integrations, schedule a placement review.