Interested in a ServiceNow event built for developers? Registration for now[dev]26 is officially open!

Best practices / additional platform performance monitoring

KaueC
Tera Contributor

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!

0 REPLIES 0