---
title: "ezgh obs alert-rules apply"
description: "Create or update an alert rule from a JSON file."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.ezghcloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ezgh obs alert-rules apply

{/* Generated by ezgh-cli's internal/tools/clidocs from the ezgh command tree. Don't edit: change the command's help in ezgh-cli and regenerate. */}

```sh
ezgh obs alert-rules apply -f <file.json> [flags]
```

Make an alert rule match a JSON file: the rule's document, as the console's JSON tab and `get -o json` show it (the fields obs-api adds, such as status and version, are ignored). The rule is the one the file's id or slug names (it must exist), else the one named name, if exactly one is. When there's none, apply creates it.

An update replaces the fields the file has (the condition whole); fields the file leaves out stay as they are. It's sent with the ETag ezgh just read: if someone saves the rule in between, nothing changes, and ezgh says to run apply again. obs-api checks the rule first: each problem is printed as path: message, and a rule that would read more than an evaluation may is refused (rule_too_expensive). Creating or changing a condition also needs read access to what it reads (obs.metrics.query, or obs.logs.search or obs.traces.search on its dataset).

Keep rule files next to the service they watch, and apply them from CI.

Part of [`ezgh obs alert-rules`](/cli/reference/obs-alert-rules).

## Examples

```sh
ezgh obs alert-rules apply -f alerts/high-latency.json
ezgh obs alert-rules get "High API latency" -o json > rule.json   # edit, then:
ezgh obs alert-rules apply -f rule.json
```

## Flags

| Flag | Type | Default | Description |
| --- | --- | --- | --- |
| `-f`, `--file` | string |  | the rule's JSON file, or - for stdin |

This command also takes the [global flags](/cli/reference#global-flags).

Source: https://docs.ezghcloud.com/cli/reference/obs-alert-rules-apply/index.mdx