Exploring Service Observability

  • Release version: Australia
  • Updated March 12, 2026
  • 4 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Exploring Service Observability

    Service Observability in ServiceNow enables operations teams to efficiently triage and manage incidents within complex, distributed production environments. It integrates telemetry data from external observability monitoring systems with configuration data from the Configuration Management Database (CMDB), presenting both within a unified workflow in the Service Operations Workspace (SOW). This integration allows teams to monitor application, infrastructure, and network health metrics related to specific services, facilitating a comprehensive understanding of service health.

    Show full answer Show less

    Key Features

    • Integration with Multiple Observability Vendors: Supports a wide range of vendors including Amazon CloudWatch, AppDynamics, Cisco ThousandEyes, Datadog, Dynatrace, LogicMonitor, Microsoft Azure Monitor, New Relic, Prometheus, SolarWinds, Splunk, and Zabbix.
    • Database Support: Supports MySQL, PostgreSQL (excluding Splunk), and Amazon RDS for CloudWatch data ingestion.
    • Service-to-Metric Mapping: Admins map CMDB services to observability metrics using vendor-specific tags, enabling consolidated visibility of related hosts, databases, and network components.
    • Unified Incident Triage: Operators can view combined health metrics, incidents, alerts, and changes for services directly in the SOW to quickly pinpoint issues without switching tools.
    • AI-Assisted Analysis: Built-in AI capabilities help generate analyses of dashboards and service health, aiding faster root cause identification.
    • Customizable Dashboards: Admins can tailor dashboard templates to display relevant metrics and information specific to their organizational needs.

    Roles and Responsibilities

    • System and Service Observability Admins: Configure connections to observability vendors, map services to data, manage users and teams, and customize dashboards.
    • Operators and Operations Managers: Use Service Observability to monitor service health, triage incidents, investigate metrics, and identify ownership for remediation.

    Practical Workflow

    Admins first determine critical services to monitor, connect observability vendor instances, and map services to telemetry data using tags. Operators then detect issues via alerts or dashboards in the SOW, review high-level health metrics, and dive deeper into observability data to diagnose root causes. This process helps identify whether issues originate from related infrastructure or network entities, enabling focused remediation efforts.

    Benefits for ServiceNow Customers

    • Comprehensive Visibility: Consolidates diverse monitoring data into a single workspace for a full-stack view of service health.
    • Faster Incident Resolution: Enables quicker identification of incident blast radius and ownership, reducing mean time to resolution (MTTR).
    • Contextual Insights: Combines health metrics with related incidents, alerts, and change information to provide actionable context.
    • Enhanced Operational Efficiency: AI-driven analyses support proactive decision-making during incident triage.
    • Seamless Integration: Embeds observability insights within Incident Management workflows and the Service Operations Workspace UI.

    Service Observability helps operations teams triage and manage incidents in a complex and distributed production system. It combines external observability monitoring systems' telemetry with related data from the Configuration Management Database (CMDB) and displays both in a single workflow in the Service Operations Workspace (SOW).

    Service Observability overview

    Service Observability displays application, infrastructure, and network health metrics in the SOW related to a given service. Metrics can be ingested from an external observability vendor (application, network, and cloud monitors) and displayed alongside information for related configuration items in the CMDB.

    Service Observability supports the following observability vendors:

    • Amazon CloudWatch
    • AppDynamics
    • Cisco ThousandEyes synthetic tests
    • Datadog
    • DynatraceSaaS and on-premise (both Classic and Grail environments)
    • LogicMonitor
    • Microsoft Azure Monitor
    • New Relic
    • Prometheus on-premise
    • SolarWinds on-premise
    • Splunk Observability and logs from Splunk Enterprise
    • Zabbix on-premise
    Service Observability supports the following databases:
    • MySQL
    • PostgreSQL (not supported with Splunk)
    • RDS (Relational Database Service) for Amazon CloudWatch

    After connecting an observability vendor to Service Observability, you map services in the CMDB to observability metrics using existing tags.

    With this data mapping, Service Observability displays metrics for entities such as host, database, or network components, along with details about related CI information. Operators use these metrics and contextual information, including current incidents and alerts, to assess service health.
    Note:
    Operators can also use the Analyze a dashboard in Service Observability and the Analyze service health in Service Observability Now Assist AI skills to generate an analysis for them.

    For example, say you use Dynatrace to monitor your checkout service, databases, and hosts, and that metrics from all these entities use the tag checkout-service to denote requests coming from that service. By mapping the checkout service CI to the Dynatrace data tagged with checkout-service, Service Observability retrieves metrics for those databases and hosts and CIs related to the service, then displays them together. Operators can pinpoint issues on entities related to the service and narrow down the mitigation process without having to leave the SOW.

    Service Observability users

    Table 1. Users
    User Description
    System admin

    System admins configure users and teams, register services to be monitored, connect Service Observability to observability vendors, and then map those services to that data. They can also view the data in the SOW
    Service Observability admin

    Service Observability admins can configure users and teams, connect Service Observability to observability vendors, and then map services to that data. They can also view the data in the SOW. Admins can also customize dashboard templates used to display metrics and related information.
    Operator/operations manager
    Note:
    These users must belong to an srm group type to see all data.
    		 Operators use Service Observability when triaging incidents in the SOW. They can view basic health metrics for a service, along with related incidents, alerts, and changes. They can get more detailed information by navigating to the Observability tab to view additional service metrics, along with metrics from related entities, such hosts, networks, or databases.

    Service Observability workflow

    Admins configure Service Observability by creating a connection to an observability vendor and then mapping CI services to that data. Operators use Service Observability to determine if another related entity is causing issues surfaced by the service's performance.

    As an admin, you:

    1. Determine the services to be monitored by Service Observability based on business criticality.
    2. Connect existing observability vendor instances to Service Observability.
    3. Map services to observability metric data using vendor-based tags attached to that data.
    4. Customize the templates used to display metric charts.

    As an operator or manager, you:

    1. Spot an issue with a service while working in the SOW, for example, from an alert, the Service dashboard, or Express List, then navigate to the Service Details page.
    2. View overall health metrics for the service, along with related incidents, alerts, and changes. If one of the metrics seems unhealthy, navigate to the Observability tab.
    3. View more detailed service metrics, as well as information from related entities, to start root cause investigation. When finding that the issue is further down the system's stack, identify the ownership for that entity to start remediation.

    Service Observability benefits

    Benefit Feature Users
    Consolidate data from existing monitoring tools, network health tools, cloud providers, ServiceNow agents, and third-party tools for a full-stack view of service health:
    • Connect data from external Observability vendors.
    • Map that data to CMDB services
    • View combined data in the SOW
    		 . Admins
    Increase efficiency and reduce mean time to resolution (MTTR). View combined metrics from entities associated with a service to begin to determine blast radius and ownership of an incident. View service health metrics Operators
    See related changes to the system and alerts associated with a service in one place. View overall service health. Operators
    Use generative AI to analyze metric data and find insights to help determine service health. Operators
    See Service Observability data as part of Incident Management workflows Digital End-User Experience and Service Observability UI experience on investigate tab Operators
    Customize dashboard templates. Customize Service Observability dashboard templates Admins

    What to explore next

    To learn more about configuring and using Service Observability, see: