---
title: Site Monitoring rules
description: Configure Site Monitoring across every site on the server — global ignore lists, alert routing, and severity tuning.
sidebar:
  order: 4
  badge:
    text: Draft
    variant: caution
---

import { Aside } from '@astrojs/starlight/components';
import SuperAdmin from '~/content/partials/super-admin-callout.mdx';
import Draft from '~/content/partials/draft-callout.mdx';
import SignIn from '~/content/partials/signing-in.mdx';
import Support from '~/content/partials/support-link.mdx';

<SuperAdmin />

<Draft />

[Site Monitoring](/whp/add-ons/monitoring/) is the customer-facing alerting product. With super admin access, you can manage the rules that drive those alerts at the server level — including a server-wide ignore list, alert routing, and severity tuning.

## Sign in to WHP

<SignIn />

## Where it lives

Sidebar → **Site Monitoring** (admin view). The page shows two perspectives:

- **Customer feed** — what your site owners see when they sign in.
- **Admin tools** — the rule library, global ignore list, and alert configuration.

## Common tasks

### Add a global ignore rule

When a signature is noisy for every site (for example, a known scanner you allow on your own infrastructure):

1. Open **Site Monitoring → Global Ignore Rules**.
2. Click **Add Rule**.
3. Define the match condition (rule_id, source IP/CIDR, URL pattern, or a combination).
4. Add a short note so future-you remembers why this exists.
5. Save. Matching events stop firing alerts immediately.

<Aside type="caution">
  Global ignore rules silence every site on the server. Prefer per-site ignore (set in the customer-facing Site Monitoring page) when the noise is site-specific.
</Aside>

### Tune severity for a rule

If a rule is set to **critical** but you've decided it's really informational in your environment:

1. Find the rule in **Site Monitoring → Rules**.
2. Open the rule and change its severity to one of: informational / warning / critical.
3. Save. The severity change applies to new events from that rule.

Severity matters because **SMS notifications fire only on critical**. Downgrading from critical to warning silences SMS without silencing the rule.

### Route alerts somewhere other than the default

Default routing: alerts go to the contact email on the account. You can:

- **Add additional email recipients** — useful for a shared ops alias.
- **Enable SMS for critical alerts** — wire your phone number on the **Alert Routing** page.
- **Forward to a webhook** — for integration with Slack, PagerDuty, or your own incident pipeline.

## Brute-force detection

Brute-force detection is a separate rule family and has its own per-site sensitivity. From the admin view, you can adjust:

- The window in which repeated failures count.
- The threshold at which the rule fires.
- Whether the rule auto-blocks the source IP (recommended) or only alerts.

## Things to know

- **Ignore lists don't stop logging.** They only suppress alerts. The events still appear in the audit feed so you can see what's actually happening.
- **Rules apply on the next log scan**, typically within a minute.
- **A muted rule for one customer doesn't affect others.** Per-site ignore is scoped tightly.

## Troubleshooting

**No alerts arriving for a known event.** Check the **Global Ignore Rules** list and any per-site ignores. Also confirm the rule's severity isn't set to informational (no email or SMS by default).

**SMS not firing on critical.** Confirm SMS is enabled in **Alert Routing** and the phone number is verified.

## Related

- [Site Monitoring add-on](/whp/add-ons/monitoring/) — what the customer sees.
- [Coraza WAF rules](/whp/admin/coraza-waf/) — request-level firewall, complements monitoring.

## Still stuck?

<Support />
