- Getting started
- Project management
- Documents
- Working with Change Impact Analysis
- Create test cases
- Assigning test cases to requirements
- Cloning test cases
- Exporting test cases
- Linking test cases in Studio to Test Manager
- Delete test cases
- Manual test cases
- Document test cases with Task Capture
- Parameters
- Enabling governance at project level
- Disabling governance at project level
- Enabling governance at test-case level
- Disabling governance at test-case level
- Managing approvers for governed test cases
- Managing governed test cases in the In Work state
- Managing governeed test cases in the In Review state
- Managing governed objects in the Signed state
- Managing comments for governed test cases
- Applying filters and views
- 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
- Project operations and utilities
- Test Manager settings
- ALM tool integration
- API integration
- Coding Agents for Testing
- Troubleshooting
Known constraints for performance testing in Test Manager, including robot runtime limits and maximum concurrent jobs.
Execution duration limits
Cloud, serverless robots can run for a maximum of 60 minutes per test. On-premises robots can exceed this limit.
Concurrency limits
-
Maximum concurrent jobs: Up to 500 jobs can run concurrently using serverless robots.
-
Impact on virtual users (VUs) — serverless: 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.
- This factor is automatically detected during the dry run and reported in the application logs. It cannot be manually overridden for serverless robots.
-
Impact on virtual users (VUs) — on-premises: On-premises robots are not capped at 2,000 VUs. With sufficient licensing, the dry run can compute a higher achievable virtual-user count, up to a hard maximum of 10,000 concurrent virtual users. Unlike serverless robots, the multiplexing factor here can be manually overridden.
-
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
Supported automation types
Performance testing is currently limited to Browser, API (HTTP WebRequest), and Desktop automations. For example, Integration Service or coded automations are not yet supported.
Within these supported automation types, Workflow Analyzer now flags specific unsupported activities automatically during dry run — see Creating automated tests for the current list.
Incognito/InPrivate mode is not supported for on-premises environments
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.
Additional limitations
Direct programmatic access to raw performance test data is not yet supported.