> For the complete documentation index, see [llms.txt](https://docs.luciq.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.luciq.ai/product-guides-and-integrations/product-guides/ai-features/agent-skills/luciq-alert-noise.md). # luciq-alert-noise Find the alert rules that fire too often to be useful, and fix them at the source. Noise isn't "an alert fired a lot" — it's "an alert fired a lot **and** the firings weren't individually worth a notification." The skill's job is to cut fatigue without cutting coverage, and every recommendation is grounded in Luciq MCP data rather than guessed from a rule's title. ## Use this skill when * The user says their alerts are too noisy. *"My alerts are too noisy"*, *"I get too many alert emails/notifications"*. * The user wants their alert setup cleaned up. *"Clean up / tune / audit my alerts"*. * The user asks which alerts are spammy or fire constantly. *"Which alerts are spammy?"*, *"stop paging me so much"*. * The user asks which alert rules fire too often in general. Not for: adding missing alerts or checking monitoring coverage (use `luciq-alert-gaps`), creating, changing, or managing one specific alert the user describes (use `luciq-alert-config`), investigating why something crashed or hung (use `luciq-debug`), or first-time SDK install (use `luciq-setup`). Resolving or acknowledging a single firing (an incident) rather than changing the rule itself is a direct one-call action, not a noise audit. ## What the agent does * **Trigger-count triage.** Pulls the full alert inventory sorted by how often each rule's conditions were met, and partitions rules into quiet (leave alone) and loud (investigate) using the product's own noise signal. * **Root-cause diagnosis.** For each loud rule, figures out *why* it's loud — a trivially low threshold, an overly broad scope, correct detection but excessive paging, an exact duplicate of another rule, or a fully redundant rule — before picking a fix. * **Safety-critical protection.** Never weakens detection or disables alerts that are supposed to fire loudly because each firing is a real emergency (a crash hitting real users, crash-free or ANR rate dropping below a safety floor). At most, it throttles the notification. * **Least-destructive remediation.** Prefers raising a threshold, narrowing scope, or adding a throttle before recommending disabling a rule, and disabling before deleting. * **Approval before writing.** Presents a per-rule remediation plan, with safety-critical rules called out separately, and only applies changes the user approves. ## Install The fastest path is the plugin install. Add the marketplace and install: ``` /plugin marketplace add luciqai/agent-skills /plugin install luciq-skills@luciq.ai ``` Works in **Claude Code** and **Cursor**. The plugin install also wires up the [Luciq MCP server](/product-guides-and-integrations/product-guides/ai-features/luciq-mcp-server.md) in one step. After install, the skill is available as `/luciq-skills:luciq-alert-noise`. For other agents, install via npm: ```bash npx luciq-skills install # project-local npx luciq-skills install --global # all projects ``` Or copy [`SKILL.md`](https://github.com/luciqai/agent-skills/blob/main/plugins/luciq-skills/skills/luciq-alert-noise/SKILL.md) from the public repo to `~/.claude/skills/luciq-alert-noise/SKILL.md` (user-global) or `.claude/skills/luciq-alert-noise/SKILL.md` (project-local). The full SKILL.md is reproduced in the expandable below.

📋 Click to expand the full SKILL.md

```markdown --- name: luciq-alert-noise description: Use when the user wants to reduce noisy, chatty, or spammy Luciq alerts, cut alert fatigue, or stop being over-notified. Triggers include "my alerts are too noisy", "I get too many alert emails/notifications", "alerts are firing constantly", "clean up / tune / audit my alerts", "which alerts are spammy", "stop paging me so much", or asking which alert rules fire too often. Inspects each alert's trigger frequency via the Luciq MCP and recommends targeted fixes (raise threshold, narrow scope, throttle, merge, or disable) — never blindly silencing a safety-critical alert. --- # Luciq Alert Noise Reduction Find the alert rules that fire too often to be useful, and fix them at the source. Noise is not "an alert fired a lot" — it is "an alert fired a lot **and the firings were not individually worth a notification**." The job is to cut fatigue without cutting coverage. Every recommendation is grounded in MCP data; never guess which alerts are noisy. ## When NOT to use this skill - The user wants to **add** missing alerts or check monitoring coverage — use `luciq-alert-gaps`. - The user wants to **create, change, or manage one specific alert** they describe — use `luciq-alert-config`. - The user is investigating *why* something crashed/hung — use `luciq-debug`. - First-time SDK install or wiring `Luciq.start(...)` — use `luciq-setup`. - The user wants to resolve/acknowledge a specific firing (incident), not change the rule. That is a one-call `write_incidents` action, not a noise audit — just do it directly. If the request fits one of the above, STOP and route there. ## Prerequisites The Luciq MCP server must be configured and authenticated. If the alert tools are not available, STOP and direct the user to set up the MCP server (or run `luciq-setup`). Tools this skill uses (verbatim names): | Tool | Action | Purpose | | --- | --- | --- | | `read_alerts` | `list` | All alert rules + their `conditions_met_count` (the rolling trigger count) and current `status`. Sort by `highest_triggered_count` to surface the worst first. | | `read_alerts` | `details` | Full payload of one rule. Call before updating, to mirror the existing shape. | | `read_alerts` | `init` | Per-app catalog of valid types/triggers/conditions/actions/operators and lookup IDs. Call before any update. | | `read_incidents` | `list` | Actual firing history with `status` (open / resolved), `type`, `count`, and timestamps. Use to judge whether firings were actionable. | | `write_alerts` | `update` | Apply a remediation to a rule. State-changing — confirm first. | | `write_alerts` | `delete` | Remove a fully redundant rule. State-changing — confirm first. | | `write_incidents` | `resolve` | Clear stale open firings as a side cleanup. | You MUST base every "this alert is noisy" claim on a value the MCP returned. Do not infer noise from a rule's title or your priors. ## What "noisy" means Luciq tracks how often each rule's conditions are met on a rolling 8-day window and exposes it as `conditions_met_count` on the `read_alerts` list response. That counter is the product's own noise signal: the dashboard treats a rule that crosses **4** matches in the window as a candidate for noise. Use `> 4` as the entry filter for "look closer", not as the verdict. A rule is genuinely noisy when both hold: 1. It fires frequently (`conditions_met_count` is high relative to the others, and well above 4), AND 2. The firings are not individually worth a separate notification — because the threshold is trivially low, the scope is too broad (no conditions), it duplicates another rule, or it pages on a non-actionable signal. A rule that fires often **and every firing matters** (a real incident stream) is not noise. The fix there is throttling the *notification*, not weakening the *detection*. ## Workflow ### Step 1. Pull the alert inventory Call `read_alerts(action: "list", sort_by: "highest_triggered_count", sort_direction: "desc")`. This is the spine of the audit. Note for each rule: `ulid`, `type`, `trigger`, `conditions`, `actions` (and any `frequency` throttle), `status`, and `conditions_met_count`. Drop disabled rules from consideration — a disabled rule is already silent. Say so if the user asked about one. ### Step 2. Triage by trigger count Partition the enabled rules: - **Quiet** (`conditions_met_count` ≤ 4): leave alone. Do not recommend changes to a rule that isn't firing much, even if it looks imperfect. Surface that they are healthy. - **Loud** (`conditions_met_count` > 4): candidates. Continue to Step 3 for each. If nothing is loud, report that plainly — "no noisy alerts, here's what you have" — and stop. Do not invent problems. ### Step 3. Diagnose each loud rule For each candidate, decide *why* it is loud before deciding the fix. When the count alone is ambiguous, call `read_incidents(action: "list", filters: { ... }, sort_by: "count")` to see whether the firings were distinct real events or the same thing over and over. Map the cause to the right remediation: | Diagnosis | Signal in the data | Remediation | | --- | --- | --- | | Threshold trivially low | e.g. `occurrences_count > 1`, `crash_free_session < 99.9`, p95 just above normal | **raise_threshold** to a meaningful level | | Scope too broad | no `conditions`, fires on every crash/request/version | **narrow_conditions** (add app_version, key_metric, endpoint, etc.) | | Detection is right, paging is too frequent | threshold sound, firings are real, but notified on every match | **add/lengthen throttle** (set `frequency` on the action) | | Exact duplicate of another rule | same `type` + `trigger` + `conditions` as a sibling | **merge** (keep one, delete the other) | | Fully redundant / obsolete | superseded by a broader rule, or watches a retired metric | **disable** or **delete** | ### Step 4. Protect safety-critical alerts Some alerts are *supposed* to fire loudly because each firing is an emergency. Never weaken detection or disable these — at most, throttle the notification. Treat as safety-critical: - `crash_affecting_percentage_of_users`, `configurable_velocity_alert` (a crash hitting real users) - `crash_free_session` / `crash_free_users_overall` below ~95% - `anr_free_users_overall` / `anr_free_sessions_overall` - `affected_users_in_time` with a large user count If one of these is loud, the recommendation is **add_throttle** or a small **raise_threshold**, with an explicit note that you are keeping detection intact. If you find yourself about to recommend disabling one, STOP — that is removing a safety net. ### Step 5. Present the plan before touching anything Output a per-rule table the user can approve: rule title, why it's noisy (cite `conditions_met_count` and the diagnosis), and the proposed remediation. Group safety-critical rules separately so the user sees they're handled conservatively. Do not write yet. ### Step 6. Apply approved remediations For each rule the user approves: 1. Call `read_alerts(action: "init", slug, mode)` to get valid fields/IDs, and `read_alerts(action: "details", ulid)` to mirror the rule's current payload. 2. Build the updated payload — change only the field the remediation targets (threshold value, an added condition, a `frequency` on the action, or `status`). Keep everything else identical. 3. Call `write_alerts(action: "update", ...)` (or `delete` for a confirmed merge/redundant rule). 4. Confirm each change back to the user with the new effective behavior. Respect the payload rules the `write_alerts` tool documents — most importantly: Overall-app/Release-rollout apdex thresholds are 0–1 decimals (send `0.9`, not `90`); all other percentages are literal; operators are stringified integers; and you may only use types/triggers/conditions that `init` exposes for this app. ### Step 7. Optional — clear stale firings If the audit surfaced open triggered alerts that are clearly stale (resolved in reality but still `open`), offer to clear them via `write_incidents(action: "resolve", ulid)`. This is cleanup, not noise reduction — keep it separate and only on request. ## Authoring changes correctly (read before any write_alerts call) Every remediation you apply goes through `write_alerts`. Produce a valid payload: 1. Call `read_alerts(action: "init", slug, mode)` first and `read_alerts(action: "details", ulid)` to mirror the rule's existing shape. Build only from what init exposes for this app; if a field isn't in init, don't send it. Never invent a tracking-tool / developer / team id — take it from init's lookup tables. 2. Wire encoding the tool expects: - Operators are **stringified integers**: `"1"`=equals, `"4"`=less than, `"5"`=greater than, `"8"`=is one of, `"3"`=contains. Send `>` as `"5"`, `<` as `"4"`. - `trigger_options.time` is the **integer key** from init's time options for that trigger — not hours/minutes. Read the key from init; never send `"1h"` or `24`. - Apdex (Overall app) thresholds are **0–1 decimals** (`0.8` for 80%, never `80`). Other percentages (crash-free, failure_rate, velocity) are literal numbers. - p95/p50 thresholds are in **seconds** (`0.5` = half a second), not milliseconds. - Crashes use `app_version_v2`, not the deprecated `app_version`. 3. Value ranges: apdex 0–1; crash-free / ANR / velocity / percentage 0–100. Never raise a threshold past these bounds. 4. Change only the field the remediation targets; keep everything else identical to the existing rule. ## Style - Quantify every claim: "fired 47 times in 8 days" beats "fires a lot". - Prefer the least destructive fix that works: raise/narrow/throttle before disable; disable before delete. - One change per rule per pass. Don't stack five edits and lose the thread. - Never present a write as done before it returns success. ## Red Flags — STOP and surface to the user - "This alert fires constantly, so disable it" — check first whether each firing is a real incident. If so, throttle, don't silence. - "It's a crash-affecting-users alert firing 40 times, let's turn it off." Never. That's the alert doing its job. Throttle the notification. - "I'll guess the threshold should be ~50." Base it on the metric's normal range from the data, or ask. Don't pull numbers from nowhere. - "I'll update the rule without calling init." Don't — you'll send IDs/triggers the app may not support and the write will fail or silently corrupt the rule. - "The user said clean up, so I'll batch-disable everything loud." Get per-rule approval. Bulk-disabling is how coverage quietly disappears. - "conditions_met_count is 3 but the title sounds spammy, I'll flag it." 3 is below the signal. Leave it. ```

## Prerequisites The Luciq MCP server must be configured and authenticated. If the alert tools aren't available, the skill stops and directs the user to set up the MCP server, or run `luciq-setup`. The skill uses these tools: | Tool | Action | Purpose | | ----------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | `read_alerts` | `list` | All alert rules with their `conditions_met_count` (rolling trigger count) and current status. Sorted by trigger count to surface the worst first. | | `read_alerts` | `details` | Full payload of one rule, read before updating to mirror its existing shape. | | `read_alerts` | `init` | Per-app catalog of valid types, triggers, conditions, actions, operators, and lookup IDs — read before any update. | | `read_incidents` | `list` | Actual firing history, used to judge whether firings were distinct real events or repeats of the same thing. | | `write_alerts` | `update` | Applies a remediation to a rule. State-changing — the agent confirms first. | | `write_alerts` | `delete` | Removes a fully redundant rule. State-changing — the agent confirms first. | | `write_incidents` | `resolve` | Clears stale open firings as an optional side cleanup. | Every "this alert is noisy" claim is based on a value the MCP actually returned — never inferred from a rule's title. {% hint style="info" %} If the alert tools aren't available, the skill stops and points the user to the [Luciq MCP server](/product-guides-and-integrations/product-guides/ai-features/luciq-mcp-server.md) setup, or to run `luciq-setup`. {% endhint %} ## What "noisy" means Luciq tracks how often each rule's conditions are met over a rolling 8-day window and exposes it as `conditions_met_count`. The dashboard treats a rule crossing 4 matches in that window as a candidate for noise — the skill uses that same threshold as an entry filter for "look closer," not as the final verdict. A rule only counts as genuinely noisy when both are true: it fires frequently, well above the entry threshold, **and** the individual firings aren't worth a separate notification — because the threshold is trivially low, the scope is too broad, it duplicates another rule, or it pages on a non-actionable signal. A rule that fires often but where every firing is a real incident isn't noise; the fix there is throttling the notification, not weakening detection. ## How the agent reduces alert noise ### Step 1. Pull the alert inventory The agent calls `read_alerts` with `action: list`, sorted by trigger count descending, and records each rule's id, type, trigger, conditions, actions, status, and `conditions_met_count`. Disabled rules are dropped from consideration, since a disabled rule is already silent. ### Step 2. Triage by trigger count The agent partitions the enabled rules into quiet (at or below the 4-match threshold, left alone) and loud (candidates for further diagnosis). If nothing is loud, it reports that plainly and stops rather than inventing problems. ### Step 3. Diagnose each loud rule For each candidate, the agent determines why it's loud before deciding on a fix, pulling firing history via `read_incidents` when the count alone doesn't make the cause obvious. It maps the cause to a remediation: | Diagnosis | Signal in the data | Remediation | | ------------------------------------------ | ----------------------------------------------------------------- | --------------------------------------------------------- | | Threshold trivially low | e.g. an occurrence count over 1, or a p95 just above normal | Raise the threshold to a meaningful level | | Scope too broad | no conditions set, fires on every crash/request/version | Narrow the conditions (app version, key metric, endpoint) | | Detection is right, paging is too frequent | threshold is sound and firings are real, but every match notifies | Add or lengthen a throttle on the action | | Exact duplicate of another rule | same type, trigger, and conditions as a sibling rule | Merge — keep one, delete the other | | Fully redundant or obsolete | superseded by a broader rule, or watches a retired metric | Disable or delete | ### Step 4. Protect safety-critical alerts Some alerts are supposed to fire loudly because every firing is an emergency — a crash hitting a real percentage of users, or crash-free/ANR rate dropping below a safety floor. The agent never weakens detection or disables these; at most it adds a throttle or a small threshold raise, with an explicit note that detection stays intact. ### Step 5. Present the plan before touching anything The agent presents a per-rule table for approval — the rule, why it's noisy (citing the actual trigger count and diagnosis), and the proposed remediation — with safety-critical rules called out separately so the user can see they're being handled conservatively. Nothing is written yet. ### Step 6. Apply approved remediations For each approved rule, the agent reads the app's `init` catalog and the rule's current `details`, changes only the field the remediation targets, and calls `write_alerts` with `update` (or `delete` for a confirmed merge or redundant rule). It confirms each change back to the user with the new effective behavior. ### Step 7. Optional — clear stale firings If the audit surfaces open triggered alerts that are clearly stale, the agent offers to clear them via `write_incidents` with `resolve`, kept as a separate, on-request cleanup rather than part of the noise-reduction recommendation itself. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.luciq.ai/product-guides-and-integrations/product-guides/ai-features/agent-skills/luciq-alert-noise.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.