Self-hosted instance maintenance - Part 2

[Gaurav Bajaj]

Continued from part 1 for self-hosted instance maintenance.

• Monitoring

During installation, customers plan to have an initial level of monitoring in place at server level. To monitor the instance, one needs to plan for holistic monitoring. Here are some key aspects of how you can monitor your instance

• HTTP availability

Maintain high HTTP availability (ideally ≥99.9%) to ensure ServiceNow is accessible for end-users and integrations and detect issues before they impact operations. This can be set up by HTTP check using FQDN or load balancer heartbeat checks.

• Server monitoring

You can plan to have your organization’s monitoring tools to track OS level metrics like CPU usage, memory, I/O wait, swap etc. inline to enterprise-wide policy. This is complemented with SAR report statistics to bring a holistic view of reporting at server levels.

• Application monitoring

This is another level of monitoring which looks inside the application and proactively identify issues based on monitoring of application logs and application metrics. This may not be required during the initial installation of platform, can be taken into consideration when platform grows beyond initial ITSM implementation.

1) App monitoring tools like Dynatrace, AppDynamics can ingest logs from ServiceNow to formulate a pattern and flag alerts in case of anomalies as well as for error and warning logs.

2) This usually requires an agent installation on the same server where ServiceNow app nodes are installed.

3) Another area is to ingest application performance metrics – Available Semaphores, CPU utilization, free memory, SQL response time by integrating using xmlstats.do page from platform.

4) For the above metrics, define the threshold and log an alert automatically. For example – Log an alert when the semaphores consumed are more than 15 or CPU utilization is more than 90% for more than 5 mins. You can work with your platform admins and monitoring tool team to identify metrics, define thresholds for each one of them and then log low, medium or critical alert on breach of thresholds.

• Periodic Architecture review and alignment

During the initial setup of a ServiceNow instance, customers typically determine server specifications, the number of nodes, and server placement based on immediate business requirements and guidance provided by ServiceNow.

In many cases, organizations begin with ITSM modules, planning to adopt Customer Service Management (CSM) or other modules later as part of their long-term roadmap. These initial decisions, however, are often based on current needs rather than anticipated platform growth, and they are rarely revisited as the platform landscape evolves. Over time, as new modules are enabled, user adoption increases, and integration with other enterprise systems expands, the original infrastructure design may no longer be optimal.

As part of robust platform governance, it is essential to regularly review and validate infrastructure decisions, including server sizing, number of nodes, high availability configuration, and network security architecture—such as DMZ placement, firewall policies, and secure access controls. This ensures that any expansion of the platform remains aligned with performance expectations, compliance requirements, and best practices for scalability and resiliency. Periodic reviews also help identify potential bottlenecks, optimize resource utilization, and proactively plan for future growth, ensuring that the ServiceNow instance continues to deliver a reliable, secure, and high-performing experience as business needs evolve.

At the end, I want to highlight that there are various other activities you can incorporate like regularly generating AWR reports (for Oracle database) to track database performance, archival performance, long running queries at database level and many other activities depending on usage load or past issue faces.

 I also want to emphasize that self-hosted instance, your responsibilities increase exponentially to manage infrastructure and therefore plan in advance and involve right stakeholders from Infra teams to ensure a stable platform.