Handling Logging After Migrating UiPath to Automation Cloud

Migrating UiPath Orchestrator from an on-premises deployment to Automation Cloud simplifies infrastructure management, but it also changes how execution logs can be accessed and consumed. Teams migrating existing Splunk-based observability pipelines often discover that familiar on-prem logging patterns no longer apply once workloads move to the cloud.

In on-prem environments, Orchestrator and robot logs are typically available as files on the server filesystem, making them easy to ingest into centralized monitoring platforms using standard forwarders. Automation Cloud removes direct access to the underlying infrastructure, forcing teams to rethink how logging should be handled after migration.

This article examines the logging challenges introduced by Automation Cloud and outlines a practical, scalable approach based on robot-level log ingestion, along with trade-offs and alternatives observed in practice.

Logging Differences in Automation Cloud

Before migration, logging workflows often depend on two assumptions:

• Log files are available on disk
• Centralized tools can access those files directly

Neither assumption holds true in Automation Cloud. Customers no longer have access to Orchestrator servers, and log files are not exposed through a filesystem. While UiPath provides APIs to retrieve logs, teams quickly encounter several limitations when attempting to rely on APIs alone.

In practice, the most common constraints include:

• Rate limiting and throttling, especially in high-volume environments
• Pagination complexity, making consistent retrieval difficult
• Latency, which delays ingestion into monitoring systems
• Incomplete metadata, depending on log type and API endpoint

For environments with audit, compliance, or operational monitoring requirements, these limitations can result in gaps in observability.

Reframing the Problem: Logging as an Observability Concern

When RPA is treated as part of a broader software platform, logging becomes an observability concern rather than a tooling issue. The question shifts from:

How do we pull logs from Orchestrator?

to:

Where can logs be generated reliably and collected without depending on cloud-specific behavior?

One effective answer is to move log generation and ingestion closer to where execution happens: the robot machines themselves.

Robot-Level Logging as an Alternative

Instead of attempting to retrieve logs from Automation Cloud, a practical approach is to collect logs directly from unattended robot hosts and forward them to Splunk (or a similar platform) using standard logging tools.

Core Components

Robot Log Configuration

UiPath robots use NLog for logging. By customizing the NLog configuration on robot machines, logs can be emitted in structured formats such as JSON. This significantly simplifies downstream parsing, indexing, and correlation.

Local Log Forwarding

Installing the Splunk Universal Forwarder on each robot machine allows logs to be collected directly from the local filesystem and forwarded to centralized indexers. This approach avoids dependency on Automation Cloud APIs entirely.

Consistent Metadata

Additional fields, such as process name, job identifiers, environment tags, or business context, can be injected at the robot level to improve searchability and correlation within Splunk dashboards.

Because this pattern operates independently of Orchestrator, log ingestion continues even if Automation Cloud services are temporarily unavailable or APIs are throttled.

Benefits of Robot-Level Ingestion

Teams adopting this approach typically observe several advantages:

• Reliability at scale: Log ingestion does not depend on API quotas or network latency to cloud services.
• Immediate availability: Logs are forwarded in near real time as processes execute.
• Operational independence: Observability remains intact during Orchestrator outages or maintenance windows.
• Alignment with standard DevOps practices: File-based log shipping is a well-understood pattern with mature tooling and operational support.

Trade-Offs and Considerations

Robot-level logging is not without limitations, and it is important to understand these trade-offs before adopting this pattern.

• Metadata gaps: Orchestrator logs include certain metadata — such as queue transaction context or retry history—that may not be present in robot logs. Teams may need to enrich logs manually where this information is required.
• Disk management: Local log generation requires log rotation and cleanup policies to prevent disk pressure on robot machines.
• Standardization effort: Ensuring consistent log formats and field naming across robots requires upfront coordination and governance.

In some environments, teams supplement robot-level ingestion with periodic API pulls from Orchestrator to capture high-value metadata, using a hybrid approach that balances completeness with operational complexity.

Alternative Approaches Seen in Practice

Community discussions around Automation Cloud logging have surfaced several alternative patterns:

• API-based ingestion: Periodically pulling logs from Orchestrator APIs can preserve richer metadata, but this approach often struggles with throttling and scalability in larger environments.
• Custom log listeners: Some teams intercept logs at runtime within workflows to push events to external systems. While flexible, this requires changes across automation packages and increases maintenance overhead.
• Hybrid strategies: Combining robot-level ingestion for execution visibility with targeted API pulls for audit data can offer a balanced solution, provided rate limits and scheduling are carefully managed.

Each approach involves trade-offs, and the right choice depends on workload volume, compliance requirements, and operational maturity.

Lessons Learned

Several practical lessons emerge when addressing logging in Automation Cloud:

• Logging strategy should be designed before migration, not after.
• Cloud APIs are useful but should not be treated as drop-in replacements for filesystem access.
• Robot-level log generation provides a stable foundation for observability at scale.
• Metadata consistency and log hygiene are just as important as log availability.

Conclusion

Automation Cloud changes how logging works, but it does not eliminate the need for reliable observability. By shifting log ingestion closer to execution and using established log-forwarding tools, teams can maintain visibility without relying on cloud-specific APIs or undocumented behavior.

Treating RPA logging as a platform engineering concern — rather than a product feature — helps ensure that automation remains observable, auditable, and maintainable as environments evolve.