Hello @TracyW69,

• Activity: Rule-Obj-Activity:pzMonitorRobotCommandAndHeartbeat is an internal Pega activity responsible for monitoring the health and status of your Pega Robotic Process Automation (RPA) bots. It periodically checks for new commands and receives heartbeat signals from active robots

It seems that the database query used to check on your robots is running too slowly. While occasional alerts might not be a major concern, frequent occurrences can indicate an underlying performance issue that could impact your robotic operations.

Possible issues:

• High Database Load: The overall load on your Pega database might be high, causing delays for all queries, including this one.

• Large Robotics Data Volume: If you have a large number of robots, or if they generate a high volume of transactions, the tables that this activity queries (like pr_sys_queue_robot_command and pr_sys_robot_heartbeat) can become very large, slowing down query performance.

• Database Performance: General database health issues, such as outdated table statistics, inefficient indexes, or contention for resources, can lead to slower query execution.

• Network Latency: Slow network communication between your Pega application server and the database server can add to the total operation time.

• Agent Scheduling: The agent (Pega-Robotic-AutomationPackageManagement) that runs this activity might be scheduled too frequently for the number of robots you have, leading to unnecessary database load.

Troubleshooting:

• Check Robotics Queue Table Size:

  • Investigate the size of the Pega RPA-related tables. A high volume of records in tables like pr_data_notification_recipient or the robot heartbeat and command queues can degrade performance. 
  • Consider a strategy for purging or archiving old, completed, or obsolete records from these tables to keep them at a manageable size. 

• PDC:

  • Use Pega Predictive Diagnostic Cloud (PDC) for identifying  performance bottlenecks in underlying robotic automations.

• Review Agent Configuration:

  • Check the scheduling of the Pega-Robotic-AutomationPackageManagement agent. If it's running very frequently (e.g., every few seconds) and you have a large number of robots, you might consider increasing the interval to reduce the load.

• Engage your Database Administrator (DBA):

  • Provide the slow SQL query to your DBA. They can perform a detailed analysis (e.g., an AWR report in Oracle) to understand the query execution plan and identify why it's slow.

  • The DBA can check for issues like missing indexes, outdated statistics, or database locking conflicts.

• Adjust Alert Thresholds (If Necessary):

  • If after investigation, the query time is deemed acceptable for your environment, you can consider adjusting the operationTimeThreshold in your prconfig.xml file.   However, this should be a last resort, as it's often better to fix the underlying performance issue rather than just suppressing the alert.