Managing Performance Policies in Leapwork Performance

This article explains how customer admins can manage performance policies in Leapwork Performance, where these policies are applied, and what they change for teams working with timelines and release gates.

It is intended for customer admins and workspace owners who need consistent performance thresholds across projects.

What performance policies are

Performance policies let admins centrally manage the response-time thresholds used for performance levels in Leapwork Performance.

Each policy defines three performance bands:

Band	Meaning
`Satisfactory`	Response times from `0` up to the satisfactory upper limit
`Tolerable`	Response times from the satisfactory limit up to the tolerable upper limit
`Frustrating`	Response times above the tolerable limit

These thresholds are used in timeline configuration and can also support consistent pass/fail decisions in CI/CD when you align your pipeline rules to the same values.

Why this matters

It keeps performance thresholds consistent across projects and teams.
It reduces manual setup when users configure timelines.
It gives admins a controlled way to apply company-wide or project-specific defaults.
It makes results, alerts, and release decisions easier to interpret against a shared standard.

Before you start

You need an admin-capable role to create, edit, or delete performance policies.
You should agree internally on which response-time expectations your teams want to use.
You should decide whether you need one company-wide policy, project-specific policies, or both.

How to manage performance policies

Open Settings in Leapwork Performance.
Go to Policy Configuration > Performance.
Select Add policy.
Enter a policy name.
Choose the scope you want to use.
Enter whole-number threshold values in milliseconds.
Save the policy.
Review and update policies whenever application behavior or service expectations change.

In practice, Organisation works as the shared company-level fallback and Project overrides it for a specific project. Custom remains available when a timeline needs manual values for a specific case.

How policies are applied

Leapwork Performance applies performance thresholds in this order:

Order	Behavior
`1`	If a project policy exists for the current project, it is used by default.
`2`	If no project policy exists, the `Organisation` policy is used.
`3`	If neither exists, Leapwork Performance uses the built-in baseline thresholds.
`4`	A timeline can still use `Custom` when manual values are needed for a specific case.

The built-in baseline thresholds are:

Band	Default range
`Satisfactory`	`0` to `250 ms`
`Tolerable`	`250 ms` to `1000 ms`
`Frustrating`	`1000 ms` and above

What users will experience when a policy is applied

In Edit Timeline, a policy selector appears under Performance level thresholds when a project or Organisation policy is available.
Selecting a project or Organisation policy applies those values and disables direct editing of the thresholds.
Selecting Custom makes the thresholds editable for that timeline item.
If admins update a project or Organisation policy later, the updated values are reflected the next time users edit affected timelines.

Impact on your testing workflow

Policies standardize how performance levels are interpreted across teams and projects.
They help teams compare runs against a shared definition of acceptable performance.
They reduce setup time for new timelines by reusing approved defaults.
They support cleaner governance when different projects need different response-time expectations.
They do not change the requests in a test or the load profile itself. They control the threshold bands used to interpret response times.

Recommended admin practices

Start with an Organisation policy if you want one consistent default across the company.
Add project policies only where a project genuinely needs different thresholds.
Keep threshold values tied to service objectives, release criteria, or internal performance targets.
Revisit policies after major releases, architecture changes, or shifts in expected traffic patterns.