Feature: Add command to modify existing alert definitions

[GuitaristForEver]

Summary

Currently cx alerts only supports create, get, list, enable, disable, and events. There is no way to update an existing alert definition in-place.

Problem

Without an update command, modifying any property of an alert (thresholds, notification channels, re-notify intervals, labels, filters) requires:

1. Fetch the existing alert with cx alerts get <id>
2. Manually edit the JSON
3. Disable the old alert with cx alerts disable <id>
4. Create a new alert with cx alerts create
5. Manually clean up the disabled alert from the UI (no cx alerts delete either)

This is error-prone and leaves stale disabled alerts accumulating in the account.

Proposed Solution

Add cx alerts update <id> that accepts the same JSON file format as cx alerts create:

cx alerts update <id> --from-file alert.json --yes

Behaviour:

• Accepts the same alertDefProperties JSON schema as create
• Performs an in-place update (preserves the alert ID)
• Returns the updated alert definition on success
• Requires --yes to match create behaviour for destructive safety

Bonus: also add cx alerts delete <id> so the full CRUD lifecycle is covered from the CLI.

Workaround

Currently using disable + create, leaving orphaned disabled alerts behind.

Environment

• cx version: 0.1.4
• Platform: Linux (Azure VM)

[Vaishnav88sk]

Assign me @niv-hertz @yonbek

[jmsundar]

+1 — hit this doing a bulk migration. cx alerts currently has create, delete, enable, disable but no update, so there's no CLI path to modify an existing alert definition in place (e.g. swapping the outbound webhook on a notification group). create from a definition file that includes the existing id doesn't update — it isn't an upsert.

For now the only working in-place edit path is the Coralogix MCP manage_alerts update action (get → modify → update). Two gaps that an update subcommand would ideally avoid, which the MCP path currently has:

• MCP manage_alerts rejects Flow/composite alerts ("unsupported alert type"), so those still can't be edited programmatically at all.
• The MCP get→update round-trip is lossy for some fields (e.g. metricThreshold rule ofTheLast comes back empty and must be re-injected), which a native cx alerts update taking the raw alert-definition JSON would sidestep.

A cx alerts update --from-file that accepts the same definition JSON as get/create (keyed by id) would cover all alert types with full fidelity.

[OmriGabai]

thanks for raising it, we'll take it internally in the team and add the functionality