Loading...
Loading...
ServiceNow previously identified that the Physical Table Monthly Stats Aggregator scheduled job could cause performance degradation in some environments. The job was configured to run simultaneously at 08:00 or 09:00 UTC across thousands of production and sub-production instances, resulting in CPU load spikes, resource contention, and sluggish system performance on shared database infrastructure. To mitigate the issue, a fix was introduced in Xanadu Patch 7 and Yokohama Patch 1, applying randomized start times to stagger execution across instances. In addition to the patch, ServiceNow conducted a round of proactive maintenance to ensure sub-production environments were properly configured ahead of the April 1 and May 1 job runs. However, it was later discovered that the fix was not consistently applied in all cases, particularly in environments affected by specific upgrade paths or instance cloning, which reset the job’s configuration to its default out-of-box value. As a result, some instances are still scheduled to run the job at 08:00 or 09:00 UTC and may be at risk of performance impact. To resolve this, ServiceNow is conducting an additional round of proactive maintenance, targeting both production and sub-production instances, to ensure proper configuration is in place ahead of the next scheduled job run on June 1, 2025.
This issue results from inconsistencies in how the fix is applied during certain upgrade paths or after instance cloning. As such, there are no manual steps to reliably reproduce the issue through standard user actions. However, to determine whether your instance may be affected, you can check the job's configuration: 1. Navigate to sys_trigger.list 2. Search for the job named "Physical Table Monthly Stats Aggregator" 3. Open the job record and review the run_time field: a. If the value is 8:00 UTC, the randomized start time has likely not been applied b. If the value appears randomized, the fix may already be present
This problem is currently under review and is targeted to be fixed in a future release. Subscribe to this Known Error article to receive updates as more information becomes available. To help prevent potential impact when the job next runs on June 1, 2025, ServiceNow is conducting proactive maintenance to apply variable start times to the Physical Table Monthly Stats Aggregator job. This change will help reduce simultaneous execution, minimize CPU load on shared database servers, and improve overall system stability. FAQs Q: What is the impact of this issue? A: Affected instances may experience slow performance, delayed database responses, or timeouts due to high CPU load on shared infrastructure. Q: Does this issue affect production instances, sub-production instances, or both? A: Both production and sub-production instances can be affected by this issue. Q: Are both production and sub-production instances being targeted with this maintenance? A: Yes. While the initial rounds of maintenance focused on sub-production environments, this round includes both production and sub-production instances to address cases where the fix was not consistently applied. Q: What is the criteria for targeting an instance with this maintenance? A: We are targeting Xanadu and Yokohama instances where the job is still scheduled to run at 08:00 or 09:00 UTC. This includes instances that may have been previously addressed but have since had the configuration reset (e.g., due to cloning or upgrade path anomalies). Q: What does the maintenance involve? A: ServiceNow will update the job’s run_time field to a randomized value, preventing simultaneous execution across instances. This reduces CPU load spikes and improves system stability. Q: When will this maintenance happen? A: The maintenance will be completed before June 1, 2025. If your instance is included, you will receive a maintenance notification with your specific window. Q: Will there be any service impact? A: No. The update takes less than five minutes, and there is no expected downtime or disruption. Q: I have an activity scheduled during the maintenance window (e.g., a deployment). Will this interfere? A: No. This maintenance does not interfere with deployments or other in-progress activities. Q: Can I opt out of this maintenance? A: Yes. Q: Can I conduct this maintenance myself? A: A customer admin can download the maintenance script here and run it on the instance via System Definition -> Scripts - Background. Q: What is the permanent fix? A: The permanent fix introduces randomized start times to stagger job execution. A more robust version of this fix will be included in Xanadu Patch 9 and Yokohama Patch 4. Q: Which versions contain the permanent fix? A: The initial fix was delivered in Xanadu Patch 7 and Yokohama Patch 1, but was not consistently applied across all upgrade paths. A new, more reliable fix will be available in Xanadu Patch 9 and Yokohama Patch 4. Q: My instance received this maintenance before. Why am I receiving it again? A: Some instances that were previously addressed may have had the fix overwritten. We are reapplying the fix to ensure the job is correctly configured ahead of the June 1, 2025 execution. Q: Do I need to do anything after the patch is applied? A: The fix is designed to apply automatically. However, if you’ve recently upgraded or cloned your instance, we recommend checking the job’s configuration to confirm successful implementation.
PRB1885210
Click on a version to see all relevant bugs
ServiceNow Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.