Best practices / additional platform performance monitoring

KaueC — Tue, 15 Sep 2026 15:56:24 GMT

Hi everyone,

We built an internal Service Portal dashboard we call WBS Hub, a Control Room that gives our team a single pane of glass for the health and performance of our ServiceNow instance, plus operational backlog and integrations. It refreshes on demand (with optional auto-refresh) and every KPI is clickable, opening the underlying list with the exact same encoded query so the number always matches the source.

Today it is organized into a few areas:

1. Platform / System health (last 15 min window)

Average response time (based on the native Semaphore Average Time indicator)
Agent Workspace average response time
RPA integration average response time
Average SQL time and average Business Rule time per transaction
Slow transactions (> 5s)
Nodes restarting (Node Start diagnostic events) and pending/processing events (sysevent)

2. Queues & Events

Pending events older than 15 min, Flow queue (QUEUED contexts)
Email outbox and send-failed emails
ECC output queue and MID Server communication errors

3. Backlog & inconsistencies (broken down by service offering / stream)

RITMs with unhandled flow errors, closed RITMs left in flow WAITING, RITMs without service offering
Flows QUEUED > 1 day, flows Presumed Interrupted
Tasks without assignment group, active tasks tied to inactive RITMs, etc.

4. Service status & overall platform health

ServiceNow platform, MID Servers, outbound email — with thresholds that flag the platform as "Healthy" or "Degraded"

We also surface some cost/operational signals on the side (ServiceNow license usage, Twilio/WhatsApp balance and consumption).

One technical note we learned along the way: on rotating tables like syslog_transaction, GlideAggregate does not return reliable AVG/MAX/SUM values, so we compute those aggregates manually via GlideRecord. COUNT remains reliable through GlideAggregate.

My question: what other platform performance monitoring would you recommend adding? We are especially interested in:

Which metrics/tables you rely on to catch performance degradation early (beyond syslog_transaction)
Whether you use Health Log / Instance Observer / Performance Analytics for this instead of custom queries, and how that compares
Good thresholds/alerting patterns for response time, SQL time, semaphore waits, scheduler/event backlog
Any signals we're missing (cache/pool saturation, long-running scheduled jobs, slow ACLs, session counts, etc.)

Thanks in advance for any tips!

question Best practices / additional platform performance monitoring in Community Central forum

Best practices / additional platform performance monitoring