---
id: ui-coverage/configuration/overview
title: Configure UI Coverage in Cypress
description: >-
  Configure Cypress UI Coverage to get a coverage score you can trust: ignore
  dynamic attributes, filter out noise, group elements, shape views, and count
  the interactions that matter.
section: ui-coverage
source_path: docs/ui-coverage/configuration/overview.mdx
version: fbc9225067c51c52ee13224e3b702cf8a025ec12
updated_at: '2026-08-14T12:36:26.878Z'
---
# Configuration overview

UI Coverage works out of the box with no setup, but a few lines of configuration make your reports match your application. Configuration lets you get a coverage score you can trust and act on by:

*   **Reflecting your app, not the framework**: ignore dynamic or auto-generated attributes so the same button is recognized as one element across snapshots instead of many.
*   **Removing noise**: filter out third-party widgets, admin-only pages, and elements your team doesn't own so the report focuses on what matters.
*   **Organizing reports around your product**: group related elements and shape how URLs roll up into [views](/llm/markdown/ui-coverage/core-concepts/views.md) that map to real pages and flows.
*   **Counting the interactions you care about**: recognize custom or plugin commands, require a meaningful interaction on specific elements, and even credit assertions as coverage.

You don't need any of this to get started, and you can add it incrementally. Reprocess a past run after each change to see the effect immediately, without re-running your tests.

**UI Coverage** turns your runs into a visual map of the interactive elements your tests exercise and the ones they miss, with no code changes or instrumentation. [Schedule a demo](https://www.cypress.io/ui-coverage?utm_medium=premium-solution-tip&utm_source=docs.cypress.io&utm_content=Schedule%20a%20demo).

## Setting configuration

Configuration lives in Cypress Cloud, not in your repository. To view or change it for a project:

1.  Open your project in Cypress Cloud and go to **Project Settings**.
2.  Select the **App Quality** tab, which holds the configuration editor.
3.  Edit the configuration as JSON, then **Save**. **Discard** reverts unsaved edits back to the last saved version.

The editor validates your JSON against the schema when you save, so an invalid configuration can't be saved, and it shows how long ago the configuration was last saved.

After you save configuration changes, you can reprocess any historical run to apply them. You can start a reprocess from two places:

*   The **Properties** tab, using the "regenerate" button next to the configuration values that were used for that run.
*   The UI Coverage report, using the "configuration updated" message that appears when you view a historical run that was processed with an older configuration.

Regenerating reports in this way allows you to make config changes and see their effects without running your Cypress tests again.

### Who can edit configuration

Editing is limited to Admin users by default. Your Cypress point-of-contact can enable editing for all users on request.

## Configuration options

For a quick overview of the practical application of the most common UI Coverage configuration properties, you can read [this blog post](https://www.cypress.io/blog/making-the-most-of-ui-coverage).

### Which option do I need?

Several options change what appears in reports and how it's organized. Pick the one that matches your goal:

| Your goal | Use |
| --- | --- |
| Control how URLs are grouped into views | [`views`](/llm/markdown/ui-coverage/configuration/views.md) |
| Remove entire views from reports | [`viewFilters`](/llm/markdown/ui-coverage/configuration/viewfilters.md) |
| Remove elements from reports and scores entirely | [`elementFilters`](/llm/markdown/ui-coverage/configuration/elementfilters.md) |
| Rename or stabilize the identity of a single element | [`elements`](/llm/markdown/ui-coverage/configuration/elements.md) |
| Combine repeated or related elements so they count as one | [`elementGroups`](/llm/markdown/ui-coverage/configuration/elementgroups.md) |
| Define groups in your application's markup instead of configuration | [`data-cy-ui-group` attribute](/llm/markdown/ui-coverage/core-concepts/element-grouping.md#Grouping-with-markup-attributes) |
| Prioritize your own attributes for identifying and naming elements | [`significantAttributes`](/llm/markdown/ui-coverage/configuration/significantattributes.md) |
| Stop dynamic or generated attributes from identifying elements | [`attributeFilters`](/llm/markdown/ui-coverage/configuration/attributefilters.md) |
| Count your custom commands as interactions | [`additionalInteractionCommands`](/llm/markdown/ui-coverage/configuration/additionalinteractioncommands.md) |
| Limit which interaction commands count for specific elements | [`allowedInteractionCommands`](/llm/markdown/ui-coverage/configuration/allowedinteractioncommands.md) |
| Apply different configuration to runs based on run tags | [`profiles`](/llm/markdown/ui-coverage/configuration/profiles.md) |

### Comments

Most configuration rules support an optional `comment` property that you can use to record why a value is set. This makes your configuration easier to understand and maintain, especially when working in a team or revisiting configuration after some time. Any rule defined as an object accepts a `comment`; the options that are plain lists of strings, such as [`significantAttributes`](/llm/markdown/ui-coverage/configuration/significantattributes.md) and [`additionalInteractionCommands`](/llm/markdown/ui-coverage/configuration/additionalinteractioncommands.md), do not take a per-entry comment.

A `comment` lives inside the rule and has no effect on behavior. Comments appear only in the configuration itself and are never displayed in reports. Because Cypress Cloud validates every rule and rejects properties it doesn't recognize, `comment` is the supported place to keep notes.

App Quality Config

```
{  "elementFilters": [    {      "selector": ".intercom-launcher",      "include": false,      "comment": "Third-party chat widget, not covered by our tests"    }  ]}
```

### Full configuration reference

The shape of every available option, with the type each value expects:

App Quality Config

```
{  // Root level only: applies to both UI Coverage and Cypress Accessibility  "views": [    {      "pattern": string,      "groupBy": string | [string],      "comment": string    }  ],  // or as a bare pattern string, if you do not want comments or grouping: "views": ["/users/*"]  // Shared properties. Valid here and, with the same shape, nested under  // "uiCoverage". If both are present, the nested list replaces the root-level one  "viewFilters": [    {      "pattern": string,      "include": boolean,      "comment": string    }  ],  "elementFilters": [    {      "selector": string,      "include": boolean,      "documentScope": [string],      "comment": string    }  ],  "significantAttributes": [    string  ],  "attributeFilters": [    {      "attribute": string,      "value": string,      "include": boolean,      "comment": string    }  ],  "comment": string,  "uiCoverage": {    // UI Coverage only    "elements": [      {        "selector": string,        "name": string,        "documentScope": [string],        "comment": string      }    ],    "elementGroups": [      {        "selector": string,        "name": string,        "documentScope": [string],        "comment": string      }    ],    "additionalInteractionCommands": [      string    ],    "allowedInteractionCommands": [      {        "selector": string,        "commands": [string],        "documentScope": [string],        "comment": string      }    ],    "comment": string    // plus viewFilters, elementFilters, significantAttributes, and    // attributeFilters: same shape as the root, replacing it for UI Coverage  },  "profiles": [    {      "name": string,      "config": {        // Any App Quality configuration options      },      "comment": string    }  ]}
```

## How rules are applied

Two behaviors govern the rules you write:

*   **Order matters** for [`views`](/llm/markdown/ui-coverage/configuration/views.md), [`viewFilters`](/llm/markdown/ui-coverage/configuration/viewfilters.md), [`elementFilters`](/llm/markdown/ui-coverage/configuration/elementfilters.md), [`elementGroups`](/llm/markdown/ui-coverage/configuration/elementgroups.md), [`attributeFilters`](/llm/markdown/ui-coverage/configuration/attributefilters.md), and [`profiles`](/llm/markdown/ui-coverage/configuration/profiles.md): rules are evaluated top to bottom and the **first** rule that matches an element or URL wins; later rules that also match it are ignored. List specific rules before broad, catch-all rules, and place an `include: true` exception above the `include: false` rule it should override. Two properties differ: for [`elements`](/llm/markdown/ui-coverage/configuration/elements.md) the **last** matching rule wins, and for [`allowedInteractionCommands`](/llm/markdown/ui-coverage/configuration/allowedinteractioncommands.md), order has no effect.
*   **Unknown properties are rejected.** When you save, Cypress Cloud validates your configuration against a strict schema and rejects anything it doesn't recognize, such as a misspelled property, a value of the wrong type, or a note on a property that doesn't accept one. Correct the flagged property to save, and keep freeform notes in a [`comment`](#Comments).

## Configuration scope

Some properties are shared across App Quality products, and some belong to UI Coverage alone.

*   **Shared properties**: `elementFilters`, `viewFilters`, `attributeFilters`, and `significantAttributes` apply to both UI Coverage and Cypress Accessibility when set at the root of your configuration. To apply one to a single product, nest it under a `uiCoverage` or `accessibility` key. A nested value **completely replaces** the root-level value for that product (the two are not merged), so repeat any shared rules you still want in the nested list. To disable a shared property for one product, nest an empty list (`"elementFilters": []`) rather than `null`, which falls back to the root value.
*   **Shared, but not nestable**: `views` applies to both UI Coverage and Cypress Accessibility and can only be set at the root.
*   **UI Coverage only**: `elementGroups`, `elements`, `additionalInteractionCommands`, and `allowedInteractionCommands` are specific to UI Coverage and are always set under the `uiCoverage` key.

## Viewing configuration for a run

Every run permanently records the exact configuration it was processed with, so the runs themselves are the history of how your configuration has changed over time. You can review a run's configuration in Cypress Cloud, or read it programmatically with the Results API.

### In Cypress Cloud

To review the configuration a specific run used, open its **Properties** tab, as shown below. This displays the configuration as it was applied when the run was processed. When you open a run that was processed with an older configuration than the one currently saved, the report flags it with a "configuration updated" message, and you can [regenerate](#Setting-configuration) the run to reprocess it with the current configuration.

### From the Results API

The [UI Coverage Results API](/llm/markdown/ui-coverage/results-api.md) exposes the applied configuration on the `config` property of its result, so you can read it in a CI workflow:

```
const { getUICoverageResults } = require('@cypress/extract-cloud-results')getUICoverageResults().then((results) => {  if (results.config) {    // ISO timestamp of when the applied configuration was last saved    console.log(results.config.updatedAt)    // The App Quality configuration that was applied to the run    console.log(results.config.value)  }})
```

If no configuration was applied to the run, `config` may be absent, so check for it before reading `value`.

## See also

*   [Views](/llm/markdown/ui-coverage/configuration/views.md)
*   [View Filters](/llm/markdown/ui-coverage/configuration/viewfilters.md)
*   [Element Filters](/llm/markdown/ui-coverage/configuration/elementfilters.md)
*   [Elements](/llm/markdown/ui-coverage/configuration/elements.md)
*   [Element Groups](/llm/markdown/ui-coverage/configuration/elementgroups.md)
*   [Significant Attributes](/llm/markdown/ui-coverage/configuration/significantattributes.md)
*   [Attribute Filters](/llm/markdown/ui-coverage/configuration/attributefilters.md)
*   [Additional Interaction Commands](/llm/markdown/ui-coverage/configuration/additionalinteractioncommands.md)
*   [Allowed Interaction Commands](/llm/markdown/ui-coverage/configuration/allowedinteractioncommands.md)
*   [Profiles](/llm/markdown/ui-coverage/configuration/profiles.md)