> For the complete documentation index, see [llms.txt](https://docs.decube.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decube.io/data-quality-v2/update-monitors-in-bulk.md).

# Update monitors in bulk

Apply monitor configuration across multiple monitors at once.

Bulk update changes monitors that already exist. Where a template gives you one configuration to create many monitors from, bulk update starts from the monitors you already have, so you pick the field you want to move and the monitors you want to move it on.

Use it to roll out a new schedule across a layer of your warehouse, tighten a threshold on everything in a schema, or attach an attribute to a fleet of monitors so your alert routing picks them up.

{% hint style="info" icon="road" %}
Today, the bulk update workflow support two monitor types: **Freshness - Staleness** and **Freshness - SLA**. More monitor types may be added soon.
{% endhint %}

To start, click **Bulk update monitors** in the **Data Quality** page header.

{% embed url="<https://youtu.be/mRLZJbIi2pk>" %}

### Step 1: Select monitors to update <a href="#step-1-select-monitors-to-update" id="step-1-select-monitors-to-update"></a>

1. Choose the **monitor type** for this update. This scopes everything that follows.
2. Narrow the list with **Filter by monitor status** and **Filter by schedule**, or search by monitor or asset name.
3. Tick the monitors you want. They collect in the panel on the right, and the counter above the list tracks your selection.
4. Click **Next: Update&#x20;*****N*****&#x20;monitors**.

<figure><img src="https://1779874722-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FTw0qpCVzfrIXqS4FEg4T%2Fuploads%2FNLaoVHnfn0M4DIYbFEmK%2FSCR-20260925-jppe.png?alt=media&amp;token=c43aea31-efe9-4c28-86a2-f31a7e4831cc" alt=""><figcaption></figcaption></figure>

### Step 2: Choose what to update <a href="#step-2-choose-what-to-update" id="step-2-choose-what-to-update"></a>

Four fields can be changed in bulk, each behind its own checkbox. Anything you leave unchecked keeps its current value on every monitor in the selection, so a batch that only moves the schedule leaves every other field alone.

* **Update dimension** sets a single data quality dimension across the selection.
* **Update attributes** sets custom attribute values across the selection. Select the attributes you want to set and give each one a value. Attributes you do not include keep whatever value each monitor already holds, so this adds and overwrites by attribute rather than replacing a monitor's whole set.
* **Update schedule** sets one frequency, timing, and timezone across the selection.
* **Update threshold** sets one value and unit across the selection.

Detection method is not a batch field, because the column each monitor reads is specific to its own table. You can still change it monitor by monitor at the review step.

<figure><img src="https://1779874722-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FTw0qpCVzfrIXqS4FEg4T%2Fuploads%2FHW81Cw8ck9Ha3LoJGju0%2FSCR-20260925-jptm.png?alt=media&amp;token=50ff2daf-24f4-4576-bd59-19e8eb61a220" alt=""><figcaption></figcaption></figure>

### Step 3: Review the changes <a href="#step-3-review-the-changes" id="step-3-review-the-changes"></a>

This step shows what each monitor's configuration will look like once the update runs.

The left panel lists one row per affected monitor. Selecting a row opens that monitor's resulting configuration on the right, where you can override any value for that monitor alone. Alongside the four batch fields, the monitor name and the detection method are editable here.

Two counts sit at the top of the step, and both are worth reading before you commit:

* **Monitors that will version**, which tells you how many monitors in the batch will be archived and replaced by a new version.
* **Monitors that need attention**, which tells you how many rows cannot be applied as they stand.

You can remove any monitor from the batch with the **X** on its row. That monitor keeps its current configuration and is left out of the update entirely.

When the batch reads correctly, click **Update&#x20;*****N*****&#x20;monitors**.

<figure><img src="https://1779874722-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FTw0qpCVzfrIXqS4FEg4T%2Fuploads%2F9GlBzvXvcAtA1i9SyFBL%2FSCR-20260925-jpvb.png?alt=media&amp;token=3c10ddd2-cc7b-493d-8042-5cd79fa7eae2" alt=""><figcaption></figcaption></figure>

#### Changes that create a new monitor version <a href="#changes-that-create-a-new-monitor-version" id="changes-that-create-a-new-monitor-version"></a>

Some changes alter what a monitor measures, which makes its collected history incomparable with what comes next. Decube handles those by archiving the current version of the monitor and starting a new one, so the old history stays intact and attributable rather than being silently mixed with readings taken under different rules. Rows affected this way carry a **Will version** badge.

| Field you change           | What happens                        |
| -------------------------- | ----------------------------------- |
| **Schedule**               | Creates a new monitor version       |
| **Detection method**       | Creates a new monitor version       |
| **Threshold**              | Applied in place without versioning |
| **Attributes**             | Applied in place without versioning |
| **Data quality dimension** | Applied in place without versioning |

A threshold change moves the line a monitor passes or fails against while the underlying measurement stays the same, which is why it applies in place. A schedule or detection method change alters the measurement itself.

#### Monitors that need your attention <a href="#monitors-that-need-your-attention" id="monitors-that-need-your-attention"></a>

A batch value does not always apply cleanly to every monitor you selected. Rows in that state carry an **Error** badge, and selecting the row names the fields that need resolving.

You have two ways forward for each flagged row: set a workable value for that monitor, or remove it from the batch and handle it separately. Resolve every flagged row before you run the update.

## Frequently Asked Questions

1. Can I bulk update Volume or Field Health monitors?

Bulk update covers **Freshness - Staleness** and **Freshness - SLA** today. Support for the other monitor types is on the roadmap, and the flow will work the same way once they arrive: pick the type, select the monitors, choose the fields, review. Until then, change those monitors one at a time from the monitor's own page on the Monitors tab.

2. Can I update Staleness and SLA monitors in the same batch?

No. One update covers one monitor type. Run a batch for each.

3. Does bulk update use a template?

No. Templates create monitors, and bulk update changes monitors that already exist. The two flows are independent, and editing a template never changes monitors that exist.

4. Will I lose monitor history?

No. Where a change creates a new monitor version, the archived version keeps its run history and the new version starts collecting from its first run. Changes that apply in place leave the history continuous.

5. What happens to monitors I remove from the list at review?

Nothing. They keep their current configuration and are left out of the update.

6. Can I undo a bulk update?

Not as a single action. Run a second bulk update to move the field back, and use the monitor's version history to see what it was set to before.
