In production, I normally check the failed job in Orchestrator first and look at the error message and stack trace.
Then I check the logs around the failure time to find which workflow/activity caused the issue.
In REFramework, I use clear Log Messages at important steps so it is easy to trace where the process stopped.
If the error is not clear, I check the input data and try to reproduce the issue in the test environment. Good logging usually makes finding the root cause much easier.
Hi @Abhinay_Reddy1 ,
You can check with the following steps:
First check Orchestrator Jobs and Logs to identify the failed process, exception message, and timestamp.
Review the Error, Business Exception, or System Exception details and correlate them with log entries.
Use detailed Log Message activities in REFramework (Start, End, Transaction ID, key variables, and error details) to pinpoint where the failure occurred.
Check the workflow and activity mentioned in the stack trace or logs to identify the exact step causing the issue.
If the error message is unclear, reproduce the issue in a lower environment and analyze input data, application state, screenshots, and execution logs.
Follow a structured logging strategy in REFramework, including transaction-level logging and exception handling, to make root cause analysis faster.
Monitor Job Logs in Orchestrator: Production exceptions can be tracked through the Job Logs. With proper exception handling or the RE Framework, exceptions are captured and the job is typically marked as Error. Filtering the logs by Error helps quickly identify process failures and review the corresponding exception details.
Check Queue Transactions: For queue-based processes, an exception will cause the transaction to be marked as Failed. The queue item will also indicate whether the failure is a Business Exception or an Application Exception, making it easier to understand the nature of the issue.
Review Email Notifications: If email notifications have been configured for Business/Application Exceptions, the relevant error details will also be available in the configured mailbox. This provides an additional way to monitor failures and initiate troubleshooting.
Configure Email Notifications: During the development phase, I would typically implement email notifications for both Business and Application Exceptions. This provides the basic error details and helps with quicker identification of production issues.
Check the Queue Transaction: I would first review the failed transaction in the Queue and check the Exception Reason field. This usually provides an initial indication of what went wrong and whether it is a Business or Application Exception.
Analyze the Failed Job Logs: Based on the transaction or queue failure timestamp, I would navigate to the corresponding Job in Orchestrator and filter the logs for Error and Fatal levels. This helps identify the detailed exception message and stack trace.
Identify the Failed RE Framework Stage: I would determine which stage failed (Init, Get Transaction Data, Process, or End) and then drill down into the relevant workflow. The failed stage often provides a strong indication of the root cause; for example, Init failures are commonly related to environment or configuration issues, while Process failures are more likely to involve transaction data, application, or UI-related issues.
Enable Workflow-Level Logging: Whenever I invoke a workflow, I leverage its properties to enable logging for successful execution. This creates clear start and completion logs, making it easier to identify exactly which workflow encountered an issue.
Add Meaningful Custom Logs: I also add appropriate log messages at key points within the workflow. This helps drill down to the exact step where the issue occurred, significantly reducing troubleshooting and root-cause analysis time.
Log Key Transaction Details at the Start: At the beginning of Process.xaml, log important transaction identifiers such as Ticket Number, Invoice ID, Customer ID, or Queue Item Reference. This makes it easier to trace a transaction throughout the process.
Use Appropriate Log Levels: Use Info for normal process execution, Warn for recoverable issues or retry scenarios, and Error for unexpected exceptions. In Catch blocks, log the actual exception details to capture the root cause.
Track Retries and Queue References: Include the retry count, Queue Item ID, and transaction reference in relevant log messages. This helps correlate failed transactions across multiple retry attempts.
Confirm Configuration at Initialization: During the Init stage, log whether the required configuration values, assets, credentials, and application settings have been successfully loaded. Avoid logging sensitive values themselves.
Add Meaningful Logs Throughout the Workflow: Log important milestones, decisions, application interactions, and key processing steps within each workflow. Well-placed logs make it much easier to pinpoint exactly where a failure occurred and troubleshoot the root cause.
Review the Failure Screenshot: For UI Automation exceptions, start by checking the screenshot captured at the time of failure. It often provides immediate visibility into the actual application state and can reveal issues such as unexpected pop-ups, changed screens, or missing elements.
Reproduce and Debug in Studio: Reproduce the issue in UiPath Studio and place breakpoints around the last successfully logged step. Step through the workflow from that point instead of running the entire process blindly. This helps isolate the exact activity causing the failure.
Check Recent Changes: Investigate what changed around the time the issue started such as application UI updates, selector changes, Windows/VM updates, browser updates, certificate expiry, or token/session expiration. These changes are common causes of previously stable automations failing unexpectedly.
Investigate Intermittent Failures: If the issue occurs intermittently, check Windows Event Viewer on the Robot machine. System-level errors such as COM exceptions, memory issues, application crashes, or RDP disconnects may provide additional details that are not visible in Orchestrator logs.
All the information provided above is from my experience, I hope this helps you understand the queries better.
From my production support experience, I usually follow a step-by-step approach:
Start with Orchestrator – Check the failed job, execution time, robot/machine, process version, and complete error message.
Check the logs around the failure – Look for the last successful step and the first error/exception. This usually helps identify where the workflow stopped.
Trace it to the workflow – Use the activity name, workflow name, and log message to locate the exact activity that failed.
Use REFramework logging properly – I prefer logging the Transaction ID, business data/reference, workflow stage, and important application actions. Also check whether it is a Business Exception or System Exception.
Investigate the root cause – Depending on the error, I check selectors, input data, application availability, credentials, file paths, API responses, network connectivity, and permissions.
Retry only after understanding the cause – If it is a temporary/system issue, retrying may resolve it. For a business/data issue, the underlying data should be corrected first.
One important practice is to avoid logging only "Process failed". Meaningful logs at key workflow stages make production troubleshooting much easier and reduce the time needed to find the root cause.