---
title: AI Monitor, Issues & Ignore Rules
description: The three admin pages that drive the Site Monitoring add-on — AI Monitor dashboard, Issues, and Ignore Rules.
sidebar:
  order: 4
---

import { Aside } from '@astrojs/starlight/components';
import SuperAdmin from '~/content/partials/super-admin-callout.mdx';
import AdminSignIn from '~/content/partials/admin-signin.mdx';
import Support from '~/content/partials/support-link.mdx';

<SuperAdmin />

[Site Monitoring](/whp/add-ons/monitoring/) is the customer-facing alerting add-on. The admin side exposes three pages — together they let you tune what gets monitored, what surfaces as a customer-visible issue, and what gets suppressed.

## Sign in as super admin

<AdminSignIn />

## AI Monitor (admin dashboard)

Sidebar → **AI Monitor → Dashboard**. The operational heartbeat of the whole monitoring pipeline.

![AI Monitor admin dashboard](~/assets/screenshots/whp/admin-monitor-admin.png)

Panels:

- **AI Log Monitor Status** — overall on/off plus three sub-statuses:
  - **Minute-cadence poll** — the cron that scans logs every minute.
  - **Health API** — the internal API that exposes per-container health.
  - **HAProxy stats** — the proxy stats feed used for error-rate tracking.
- **Stat tiles** — Last Run, Errors Tracked, Remediations, API Calls Today (with a rate-limit denominator).
- **Health Check Timeline (last 7d)** — every state transition (`cpu`, `swap`, `haproxy`, etc.) with its severity and an **AI Diagnosis** explanation.

Use this page to confirm the pipeline is healthy and to drill into recent state changes. The AI Diagnosis text gives a plain-language summary of *why* a transition happened — useful for context before you act.

## Issues

Sidebar → **AI Monitor → Issues**. The customer-visible findings, server-wide.

![Issues page](~/assets/screenshots/whp/admin-issues.png)

Four stat tiles at the top:

- **Critical** — open critical-severity issues.
- **Warning** — open warning-severity issues.
- **Auto-resolved (review)** — issues the monitor closed on its own that may still need a human glance.
- **Active suppressions** — issues currently muted by an Ignore Rule.

Filter row: Scope (All / specific user), Status (Open / Closed / All), Severity, Source, Signature prefix.

Bulk actions: **Mark Fixed**, **Ignore**, **Delete**.

Each row has its own quick-actions: **Fix** (close it) and **Ignore** (create an ignore rule from this row's match criteria).

## Ignore Rules

Sidebar → **AI Monitor → Ignore Rules**. Match criteria that prevent matching findings from becoming customer-visible issues.

![AI Monitor Ignore Rules page](~/assets/screenshots/whp/admin-ignore-rules.png)

Each rule has these fields:

- **Scope** — `user` (just one customer) or `global` (every customer).
- **Target** — the user or domain the rule applies to.
- **Match** — a comma-separated set of `field=value` predicates (e.g. `cat=degraded & title~"Beaver Builder cache files missing"`). Match fields combine with **AND** semantics — every predicate must match.
- **Reason** — a short note for future-you explaining why the rule exists.
- **Hits / Last hit** — how often the rule has matched, and when.
- **Enabled** — toggle without deleting.

<Aside type="tip">
  Prefer **per-user** ignores over global. Global rules silence the finding for everyone on the server.
</Aside>

## Common tasks

### Mute a known-noisy finding for one customer

1. Open **Issues**, find the row.
2. Click the row's **Ignore** action — that pre-fills an Ignore Rule with the matching criteria scoped to that user.
3. Add a **Reason** so future-you (or someone else on the team) understands why it exists.
4. Save. Future matching findings will be suppressed; the **Active suppressions** tile will tick up.

### Investigate an "Auto-resolved (review)" issue

These are issues where the underlying signal recovered before a human looked at them. Open the row to see the AI Diagnosis and the original detection. If the resolution looks legitimate, click **Mark Fixed**; if you're suspicious, leave it open and add a comment for context.

### Tune brute-force detection

Brute-force rules live in **Coraza Rules** (rule families CRS-913 / 921 / 942 / 949) rather than AI Monitor. AI Monitor surfaces the *effects* (error spikes) once a brute-force pattern fires, but the matching itself is in the WAF — see [Coraza WAF rules](/whp/admin/coraza-waf/).

## Routing alerts

Customer email alerts are sent via the SMTP relay configured on **Server Settings → Mail → Outbound Email (SMTP)**. Toggle **Enable Outbound Email** off there if you need to silence outbound notifications for a maintenance window.

## Troubleshooting

**Pipeline shows "stale" — Last Run more than a few minutes ago.** Check the cron's container on **Server Settings → Services → Docker Container Management**. The monitor poll is `whp-monitor-poll`.

**Issues appearing for a known noisy site.** Add an Ignore Rule scoped to that user.

**No customer alerts arriving.** Confirm Outbound Email is enabled and the SMTP relay is reachable from the server.

## Related

- [Site Monitoring add-on](/whp/add-ons/monitoring/) — the customer-facing side.
- [Coraza WAF rules](/whp/admin/coraza-waf/) — request-level firewall.
- [Server settings & services](/whp/admin/server-settings/) — SMTP relay config for outbound alerts.

## Still stuck?

<Support />