Issue   

On Pega Cloud environments running Customer Decision Hub™ (CDH), initiating a wake-up from hibernation can leave the environment stuck in a "Waking Up" state indefinitely. The ADM (Adaptive Decision Manager) service takes longer to initialize than the Kubernetes startup probe allows, causing the CDH pod to fail its health check, restart repeatedly, and block environment availability. 

This issue has a pattern of weekly recurrence on environments scheduled for weekend hibernation. 

Symptoms and Impact

• Environment status remains "Waking Up" for more than 25–30 minutes after a wake-up is initiated from My Pega Cloud. 
• PDC shows alerts with the message: "DSM service node is unreachable" 
• ADM.Default service startup takes 6–7 minutes, exceeding the default 5-minute Kubernetes startup probe threshold. 
• CDH pods enter a continuous restart loop, preventing the environment from reaching Running status. 
• All users are blocked from accessing the environment until Cloud Ops intervenes. 
• Issue recurs each time the environment wakes from hibernation (typically Monday mornings after weekend hibernation). 

Steps to reproduce

1. On a Pega Cloud™ CDH environment running Pega Platform™ '25.1.x, allow the environment to enter hibernation (for example, via scheduled weekend hibernation). 
2. Initiate a wake-up from My Pega Cloud.  
   1. Navigate to My Pega Cloud > My cloud setup > View details.  
   2. Locate the environment in Hibernated status, click the More icon, and select Wake up. 
3. Observe the environment status in My Pega Cloud.  
   1. Status enters "Waking Up" but does not transition to "Running" within 30 minutes.  
   2. In PDC, review active alerts — the error "DSM service node is unreachable" appears. 
4. Review PegaRULES logs on the CDH pod.   
   • ADM.Default startup exceeds 5–6 minutes.  
   • The log entry shows: [Invalid models identifier] Invalid factory key found. 

Root Cause

 The startup delay is caused by a reconciliation task that scans the full Rule-Decision-Strategy dataset at startup — including a large volume of rules that are irrelevant to prediction configuration.  

When an environment wakes from hibernation, all application caches including database connection pools are cleared. The PredictionConfigurationReconciliationTask runs during ADM service startup to reconcile all prediction configurations.  

This task uses PredictionRuleBrowser to load all Rule-Decision-Strategy records from the database and then filter in memory for prediction strategies only. This results in: 

• Unnecessary scan and deserialization of the full strategy rule dataset (663 rules scanned, 47 relevant — ~7% efficiency). 
• Over-matching of stale legacy multi-stage strategies through in-memory custom field checks. 
• Startup duration extending well beyond the 5-minute Kubernetes startup probe threshold, causing the pod to be marked unhealthy and triggering a restart loop. 

On environments that also carry invalid ADM model factory records (for example, models missing the pyTreatment field, created before that field was introduced in a prior platform version), the reconciliation is further extended. These records accumulate naturally across platform upgrades and are inert during normal restarts — the full validation is only triggered on cold starts, which is why the symptom is exclusive to hibernation wake-up. 

Solution

Update to Pega Infinity™ '25.1.4 which already contains the product fix. 

The fix will also be applied in upcoming Patch releases for Infinity ‘26 and Infinity ‘27.  This document will be updated once the Patch releases are announced. 

The fix makes two targeted changes: 

1. PredictionRuleBrowser now filters Rule-Decision-Strategy records at the database level using pyInterface = "Prediction", eliminating the full-table scan and in-memory filtering pass entirely. 
2. PredictionConfigurationReconciliationTask now emits a full timing breakdown at INFO level (no longer hidden behind DEBUG), including: 
   • configKeyLoad 
   • ruleBrowseOnly 
   • createAndSaveConfig 
   • total 
   • Count of rules scanned and count of matched prediction strategies

With the fix in place, ADM cold-start reconciliation is scoped to only the records that matter, reducing startup time and making performance regressions observable in production logs without requiring a log level change. 

Local Change (For releases where fix is not yet applied) 

The workaround has two parts: removing invalid model records that extend startup time and excluding the environment from hibernation to prevent recurrence. 

Part 1 — Remove invalid ADM model factory records (Cloud Ops action required) 

Raise a Cloud Change to execute a database cleanup using the activity pxDeleteModelsByCriteria (class: DSMPublicAPI-ADM). 

Recommended parameter values: 

• SelectByRuleAppliesTo = true 
• RuleAppliesTo = Data-Decision-Request-Customer 
• SelectByTreatment = true 
• Treatment = (empty string) 
• UseForceDelete = yes 
• AlsoDeleteFromDatamart = true 

This targets models where pyTreatment is missing or empty — the records causing the extended reconciliation pass. After cleanup, ADM cold-start time should return to 1–3 minutes, below the probe threshold. 

Part 2 — Temporarily exclude the environment from hibernation 

Submit a Cloud Change to add the affected environment to the hibernation exclusion list. This prevents recurrence while the product fix is validated. 

Recommendation/Best Practice

Reduce the large number of Rule-Decision-Strategy records in the codebase.  Reducing the number of unnecessary rules shortens the execution time of PredictionConfigurationReconciliationTask and improves ADM startup turnaround time. 

References

Managing hibernated environments in Pega Cloud

PEGA0076 alert — DSM service node is unreachable