- Getting started
- Project management
- Documents
- Working with Change Impact Analysis
- Importing Orchestrator test sets
- Creating test sets
- Adding test cases to a test set
- Assigning default users in test set execution
- Enabling activity coverage
- Enabling Healing Agent
- Configuring test sets for specific execution folders and robots
- Overriding parameters
- Cloning test sets
- Exporting test sets
- Applying filters and views
- Creating automated tests
- Executing performance scenarios
- Known limitations for performance testing
- Best practices for performance testing
- Troubleshooting performance testing
- Accessibility testing for Test Cloud
- Searching with Autopilot
- Project operations and utilities
- Test Manager settings
- ALM tool integration
- API integration
- Troubleshooting
Test Manager user guide
Cloud, serverless robots can run for a maximum of 60 minutes per test. On-premises robots can exceed this limit.
-
Maximum concurrent jobs:
Up to 500 jobs can run concurrently using serverless robots.
-
Impact on virtual users (VUs):
The number of achievable virtual users depends on multiplexing (multiple VUs per job).
For example, with a multiplexing factor of 4, a scenario can scale up to 2,000 concurrent virtual users.
The multiplexing capabilities for serverless robots are automatically detected during the dry run, and the resulting factor is reported in the application logs.
Unlike on-premises machines, where the multiplexing factor can be manually overridden, this is not supported for serverless robots.
-
VPN constraints:
When using a VPN, the effective concurrency depends on the VPN or gateway capacity.
-
Default limit: ~250 concurrent jobs
-
The actual limit may vary based on the gateway SKU and infrastructure capacity.
-
If higher concurrency is required, customers should contact UiPath support or their account team to discuss VPN scaling options.
-
-
Execution duration:
Serverless robots are limited to 60 minutes per execution
HTTP
WebRequest), and Desktop automations. For example, Integration Service or coded
automations are not yet supported.
Performance Testing executions on on-premises machines do not support browser automation in Chrome Incognito mode or Edge InPrivate mode.
This limitation is caused by browser security restrictions that require extensions to be manually enabled for private browsing. Although the UiPath browser extension can be installed (for example, via Group Policy), it cannot be automatically enabled in incognito mode, which prevents the automation from interacting with the browser during test execution.
Additionally, Performance Testing creates new browser user directories for each execution. Enabling the extension for incognito mode would require manual configuration for each of these directories, making it impractical for automated scenarios. For more information, refer to the Alternative for enabling incognito mode section of the Studio documentation.
This limitation applies only to on-premises environments.
In serverless environments, Incognito mode is supported because the browser configuration is fully managed by UiPath.
Workaround: Run tests in standard browser mode.
Performance Testing creates its own dedicated browser profile and directory, ensuring it does not interfere with the user’s default profile. This setup allows tests to run in a sandboxed environment, similar to an incognito mode. After execution, all browser directories created for testing are cleaned up, leaving no residual data.
- Infrastructure gaps:
ACR-VMsupport and elastic provisioning are not yet available, so automatic scaling of resources is currently not possible. - API access: Direct programmatic access to raw performance test data is not yet supported.
- Historical comparison: Test results from different historical runs cannot yet be compared.
- Autopilot and agentic support: Autopilot and agentic support are not available in the current release.
- Recordings displayed in the detail: Recording can be activated and viewd only in Orchestrator.