---
version: "2026"
language: "en"
---
# Managing Go Policies in Leapwork Go

This article explains how customer admins can manage performance policies in Leapwork Go, 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

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

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

1. Open `Settings` in Leapwork Go.

2. Go to `Policy Configuration` \> `Go`.

3. Select `Add policy`.

4. Enter a policy name.

5. Choose the scope you want to use.

6. Enter whole-number threshold values in milliseconds.

7. Save the policy.

8. 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 Go 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 Go 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 `Go 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.