How to Monitor ArcGIS Enterprise Health

ARCGIS ENTERPRISE How to Monitor ArcGIS Enterprise Health A Practical Guide for GIS Administrators & IT Teams Architecture  ·  APIs  ·  ArcGIS Monitor  ·  Infrastructure  ·  Best Practices
3 Monitoring Layers	4 Built-in Tools	9 Checklist Items	6 Action Steps

 

Table of Contents                                                                                                

 

Why Monitoring ArcGIS Enterprise Is Different
Built-In Tools You Already Have
Health Check Endpoints
The Enterprise-Wide Health Check Suite
The Metrics API
Logs
ArcGIS Monitor: Esri's Dedicated Observability Product
Don't Forget Infrastructure & External Monitoring
A Practical Health Checklist
Putting It Together

Introduction

A Web GIS deployment rarely fails all at once. It usually starts small a federated server that silently drops offline, a Data Store volume quietly filling up, a certificate that expires on a Friday night. By the time end users notice broken maps or login errors, the root cause is often hours or days old.

Proactive monitoring turns those incidents from emergencies into routine maintenance. This guide walks through every layer from the free tools built into ArcGIS Enterprise, to Esri's dedicated observability product, to the infrastructure and external checks your platform tooling won't catch.

Why Monitoring ArcGIS Enterprise Is Different

ArcGIS Enterprise isn't a single application it's a distributed system made up of Portal for ArcGIS, one or more federated ArcGIS Server sites, a relational Data Store, a tile cache store, optionally a spatiotemporal big data store, and Web Adaptors tying it all together.

A "healthy" deployment means every one of those components is reachable, properly federated, resourced, and in sync. Monitoring must cover three distinct layers: 

1 Infrastructure	2 Component Health	3 Usage & Performance
▸ CPU & memory on all hosts ▸ Disk I/O & storage volumes ▸ Network throughput & latency ▸ Certificate expiration	▸ Portal healthCheck endpoint ▸ Server healthCheck endpoint ▸ Data Store replication ▸ Federation status	▸ Service instance utilization ▸ Web app & map sessions ▸ Log error/warning rates ▸ Database query latency

 

The most common monitoring mistake: treating ArcGIS Enterprise as a single service and checking only the Web Adaptor URL which can report "up" even when one of the underlying machines has failed.

 Built-In Tools You Already Have

Before reaching for a third-party product, it's worth knowing what ships with ArcGIS Enterprise itself. These tools are free, reliable, and directly queryable from scripts or monitoring platforms.

Health Check Endpoints

Both Portal and Server expose a lightweight healthCheck REST endpoint designed for load balancers and external monitors. An HTTP 200 response means the machine can receive and process requests:

 

# Portal health check https://portal.domain.com:7443/arcgis/portaladmin/healthCheck?f=pjson   # Server health check https://server.domain.com:6443/arcgis/admin/healthCheck?f=pjson

💡 Important Point your load balancer at these URLs on every machine individually not just through the Web Adaptor. Checking only the Web Adaptor can mask a single failed machine behind working ones.

 The Enterprise-Wide Health Check Suite

Newer ArcGIS Enterprise releases add an asynchronous health check suite triggered through the Administrator API. It runs a battery of tests and returns a structured pass/fail report:

POST /<context>/admin/healthCheck/run Content-Type: application/x-www-form-urlencoded   suiteIds=BSHC-001&runName=nightly-check&f=pjson&token=<your-token>

 

💡 Automation tip Schedule this via cron, Task Scheduler, or the ArcGIS API for Python to run nightly. Route the JSON result to email or a Teams/Slack webhook so your team sees issues before users do.

The Metrics API

ArcGIS Enterprise's Administrator API exposes a metrics endpoint that captures real-time data about all platform components and the host machines they run on the same data that powers ArcGIS Monitor internally.

This is queryable directly for building custom lightweight dashboards or feeding metrics into existing observability platforms (Grafana, Datadog, etc.) without purchasing a separate product.

Logs

Portal and Server both expose a /logs/query admin endpoint with five log levels (SEVERE → FINEST). Centralizing these logs lets you correlate error spikes with specific services, machines, or time windows without hunting through files manually.

•    Recommended tools: ELK Stack (Elasticsearch + Logstash + Kibana), Splunk, Azure Monitor, or AWS CloudWatch

•    Set alerts: any SEVERE log entry, or a spike in WARNING entries, should trigger a notification 

ArcGIS Monitor: Esri's Dedicated Observability Product

For organizations running more than a handful of machines, Esri's purpose-built product ArcGIS Monitor is worth a serious look. It works as an extension to ArcGIS Enterprise on Windows or Linux, on-premises or in the cloud and provides a single console across multiple deployments and release versions. 

ArcGIS Monitor 2026.0 adds portal web app & web map usage metrics, plus per-machine CPU, memory, and instance utilization for multi-machine ArcGIS Server sites making it significantly easier to right-size server infrastructure.

 Key capabilities over and above the raw APIs:

•    Component relationship graphs : visualize dependencies between Portal, Server sites, databases, and host machines to immediately see the blast radius of any failure

•    Configurable alerts & notifications : receive email or webhook alerts when metrics cross administrator-defined thresholds

•    Database & geodatabase metrics : including custom SQL queries against registered databases

•    Web app & web map usage analytics : concurrent sessions, session length, and usage trends across the organization (new in 2026.0)

•    Multi-machine service utilization : CPU, memory, and instance counts broken out per machine and per service (new in 2026.0)

•    Cross-deployment visibility : a single pane of glass across multiple ArcGIS Enterprise deployments running different versions

•    Status checks beyond your deployment : ArcGIS Online availability and third-party ArcGIS Server site status 

💡 Real-world result One regional government agency tracked two enterprise portals, three ArcGIS Server deployments, 21 databases, 9 host machines, 600+ services, and 18+ storage sites in Monitor replacing reactive firefighting with proactive bottleneck detection.

 

Don't Forget Infrastructure & External Monitoring

ArcGIS-aware tools only tell half the story. Layer in general-purpose infrastructure monitoring so you catch problems that ArcGIS-specific tooling won't:

 

•    OS & infrastructure monitoring (Prometheus + Grafana, Datadog, Nagios, Zabbix, or cloud-native tooling) CPU, memory, disk I/O, and network latency on every host machine

•    Disk space alerts on Data Store volumes : the relational and tile cache stores are the most common place for slow-building, silent outages

•    Certificate expiration monitoring : for every HTTPS endpoint; set alerts 60 and 30 days before expiry

•    Database-level monitoring : PostgreSQL pg_stat_activity, SQL Server DMVs for connection counts, long-running queries, and replication lag

•    Synthetic uptime checks : external pings hitting your public Web Adaptor URL the way a real user would, from outside the network perimeter

A Practical Health Checklist

Use this table as a daily or weekly review checklist. Each row represents a distinct failure mode that monitoring should detect before users do. 

Area	What to Watch	Why It Matters
Federation	Server-to-Portal federation status	A dropped federation silently breaks publishing and item access
Services	Instance usage, min/max instance counts	Maxed-out instances cause slow or failed requests under load
Data Store	Disk space, replication status (HA)	Running out of space halts edits and new hosted layers
Certificates	Expiration dates on all HTTPS endpoints	Expired certs cause hard outages with little warning
Backups	webgisdr job success/failure	An untested or failing backup isn't a backup
Logs	Error/warning rate trends	Early signal of degrading components before full failure
Licensing	License expiration dates	Expired licenses can disable services without obvious symptoms
External dependencies	ArcGIS Online connectivity, identity provider availability	SSO or online-content failures often originate outside your deployment

 

Putting It Together: A Layered Strategy

The most resilient monitoring setups don't rely on a single tool they layer multiple approaches so gaps in one are caught by another. Here's the recommended implementation sequence:

 

1	2	3	4	5	6
Wire health-check endpoints	Schedule nightly health suite	Centralize logs	Adopt ArcGIS Monitor	Monitor infrastructure	Test recovery
Connect Portal & Server /healthCheck to your load balancer for automatic failover	Run the Enterprise health check API and route results to your team channel	Ship logs to ELK, Splunk, or Azure Monitor and alert on SEVERE entries	Add dashboards, alerts, and usage analytics once the deployment grows	Add disk, cert, and DB monitoring with general-purpose tools	Test backups and failover regularly a plan untested isn't a plan

  

Healthy ArcGIS Enterprise deployments aren't the ones that never have problems they're the ones where the team finds out about problems before the users do.