# Notifications > One pipeline for everything the server needs to tell you — certificate renewals, backups, imports, disk usage, services — in the panel and by email, with the noise controls that keep it worth reading. Source: https://www.corepanel.net/docs/notifications/ Last updated: 2026-08-19 Part of the CorePanel documentation — https://www.corepanel.net/docs --- Every part of CorePanel reports what it does through one pipeline: certificate renewals, backups, imports, disk usage, services, WordPress installs. Before this existed those outcomes ended in a log file, which is another way of saying nobody saw them until something had already broken. Notifications are available in **every edition**. This is operational hygiene, not a paid feature. ## Where they show up **The bell** in the top bar carries the unread count and the ten most recent unread entries. **Notifications** in the sidebar is the full list, with filters and the delivery state of each entry. ![The Notifications page: a filter row for severity, module and unread-only above a table whose rows carry a coloured severity chip, the event text with the module beneath it, the affected account, when it happened and whether it was emailed. Unread rows are highlighted; a repeated certificate failure shows a ×3 chip, and two informational entries are marked "Panel only". The header bell shows an unread badge of 4.](https://www.corepanel.net/_astro/notifications-list.MtpiL0Db.svg) Each entry has: | | | |---|---| | **Severity** | Critical, Error, Warning or Info — this is what decides how it is delivered | | **Event** | What happened, plus the module it came from | | **Account** | The hosting account affected, when the event is about one | | **When** | The first time it happened | | **Email** | Whether it was emailed, and if not, why | A **`×N`** beside an event means the same thing happened N times and was folded into one entry. Folding only happens while the entry is **unread**: once you have seen it, the next occurrence is news again and gets its own row. That is what keeps a service flapping every five minutes from producing three hundred rows overnight, without hiding the fact that it flapped again after you looked. ## Severity decides the delivery | Severity | In the panel | By email | |---|---|---| | **Critical** | ✓ | Immediately — within about a minute | | **Error** | ✓ | In the next digest | | **Warning** | ✓ | In the next digest | | **Info** | ✓ | Never to an operator; panel only | The last row is the deliberate asymmetry. "A backup completed" is worth having in the panel and is not worth an email to the person who runs the server — but it *is* exactly the mail a hosting customer wants about their own account, and that is how it is treated when the recipient is an account owner. ## Who gets told An event is routed by what it is, not by which part of CorePanel produced it. Three audiences, each getting **its own copy** with its own read state and its own email: | Audience | Who | Where the mail goes | |---|---|---| | **Administrator** | Whoever runs this server | The server's administrator email | | **Reseller** | The reseller that owns the affected account | The reseller's contact email | | **Account owner** | The hosting customer | The account's owner email | Reading an alert as the administrator does **not** mark it read for the customer — they have not seen it. On **Business**, the account owner's copy is not only emailed: the customer reads it in their own panel, under **Notifications**, and chooses there whether it is emailed to them at all — see [the client panel](https://www.corepanel.net/docs/client-panel#notifications). What they get is their own audience and nothing else; the administrator's copy of the same event, and every event about the server itself, stays yours. Two consequences worth knowing: - **A server-wide event reaches the administrator alone.** A failed renewal on a customer's domain concerns its owner; the same failure on the server's own hostname certificate concerns nobody but you, and it carries no account, so that is where it stops. - **On a server with no resellers there is no reseller copy.** The primary vendor's operator is the administrator, who already has one. ## Settings **Notifications → Notification email**, visible to super-administrators because these are server-wide. A hosting customer has a card of their own with the first two of these settings and neither of the last three: the digest interval and the From address belong to the server, and sending a test is an operator's diagnostic. - **Send notification email** — off keeps everything in the panel and mails none of it. - **Minimum severity** — the floor that reaches your mailbox. Warning by default. - **Digest interval** — hourly or daily. How often the non-critical events are bundled into a single message, grouped by module. - **Send from** — the address the messages come from. Empty means `corepanel@`. - **Send test notification** — one email now, ignoring the severity policy and the rate limit. Use it before you need it. ### The rate limit A recipient receives at most **ten emails per hour**. It counts emails, not events: a digest carrying forty entries is one email. When the cap is reached, the remaining alerts fold into that recipient's next digest, which says how many were folded in. A runaway producer can neither flood your mailbox nor a customer's, and one noisy account cannot consume another's budget. ## Making the email actually arrive This is the part that is not a CorePanel setting, and it decides whether the feature works for you. **A fresh VPS is a poor sender.** `corepanel@` with no SPF record, no DKIM signature and no matching reverse DNS is exactly the profile Gmail and Outlook drop silently. Your own alerts landing in your spam folder is survivable; a customer's "your WordPress is ready" landing in theirs makes your hosting look broken. Three ways out, in the order most people take them: 1. **Publish the records for your hostname.** If the hostname's DNS zone is on this server, CorePanel signs with DKIM and publishes SPF for you. If it is at a registrar elsewhere — the common case — add them there: | Record | Name | Value | |---|---|---| | SPF (TXT) | `` | `v=spf1 a mx ~all` | | PTR | (at your provider) | must resolve to `` | The PTR is set in your VPS provider's control panel, not in DNS you host. A mismatched or missing one is the single most common reason this mail is discarded. 2. **Send from a domain you already send from.** Set **Send from** to an address on a domain with working SPF/DKIM, and the messages inherit its reputation. 3. **Relay through a provider.** Configure a `relayhost` in Postfix (SES, Postmark, Mailgun, your own MX). This is a Postfix change, outside CorePanel, and it is the only option that gives you delivery reports. > **What CorePanel promises here** > > Best-effort delivery through the local mail server. "Emailed" in the panel means the > message was **accepted by Postfix** — not that it reached an inbox. Bounces land in the > local `root` mailbox like any other. This is a useful alerting channel; it is not one to > bet an SLA on. ### When the mailbox is inside the account that broke `Account is out of disk space` sent to an address hosted on this same server, inside that same account, cannot be delivered — the delivery fails precisely because the alert is true. CorePanel detects this, leaves the entry in the panel marked **"Not emailed — the mailbox is inside the affected account"**, and adds a note to the administrator's copy. It never redirects a customer's mail to the administrator: that would put one customer's operational detail in somebody else's mailbox. ## Reading the Email column | Shown | Meaning | |---|---| | **Emailed** | Handed to the local mail server | | **Queued** | Not decided yet; the next pass (once a minute) will | | **Panel only** | Below the recipient's minimum severity — by design | | **Not emailed — no address on file** | The recipient has no email address | | **Not emailed — email is turned off** | The recipient disabled notification email | | **Not emailed — the mailbox is inside the affected account** | See above | | **Folded into the next digest** | The hourly cap was reached | | **The mail server refused it** | Postfix rejected the submission — check its log | ## What triggers a notification | Event | Severity | Who hears | |---|---|---| | Certificate renewal failed | Error | Administrator, reseller, owner | | Commercial certificate expiring (30, 14, 7, 3, 1 days) | Warning | Administrator, reseller, owner | | Backup failed | Error | Administrator, reseller | | Backup completed | Info | Administrator, owner | | Restore failed | Error | Administrator, reseller, owner | | Import completed / failed | Info / Error | Administrator, owner / Administrator, reseller | | Disk nearly full (server) | Critical | Administrator | | Service stopped running | Critical | Administrator | | Application stopped answering | Error | Administrator, owner | | Panel logins rate limited | Warning | Administrator | | [Repeated failed mail logins from one address](https://www.corepanel.net/docs/security/access-protection) | Warning | Administrator | | WordPress installed | Info | Owner | | WordPress install failed | Error | Administrator, reseller, owner | | Account nearing / over its disk limit | Warning / Critical | Reseller, owner / all three | | Account created | Info | Reseller, owner | There is deliberately **no expiry warning for automatic certificates**. One about to expire either renews itself — making the warning noise — or fails to, and then "renewal failed" has already said so with the reason attached. Two alerts for the same fact train you to ignore both. Expiry warnings exist only for certificates a human has to go and buy. The commercial one reaches the **owner** because, since customers [install their own certificates](https://www.corepanel.net/docs/ssl-certificates), the customer is usually the only person who can buy the renewal. It fires on a ladder — 30, 14, 7, 3 and 1 days, then on expiry — rather than every day the certificate is inside the window, which would be thirty mails for one errand. Its wording distinguishes the two outcomes: a host with an automatic certificate underneath changes issuer, a host without one loses HTTPS. The second case is the only event in this table that keeps repeating daily until somebody acts, because it is the only one where the site is actually down. > **Passwords are never in a notification** > > The events that most invite it — a new WordPress site, a new account — carry the site URL, > the admin URL and the username, and say where to get a password. They never carry the > password itself. A notification is stored for months, rendered in the panel and mailed in > plain text; a credential there is a credential leaked three ways. CorePanel refuses > credential-looking fields outright rather than relying on anyone remembering. ## Retention | | Kept for | |---|---| | Read notifications | 90 days | | Unread notifications | 180 days | | Per recipient | The 2 000 most recent | The cap is per recipient, not per server: one busy account cannot evict every other customer's history. ## From the CLI The CLI is root-local and may therefore read **every** audience — which is what answers "did my customer actually get that mail?". ```bash # What has the server been trying to tell me? corepanel notifications list --unread # Only the things that are actually on fire corepanel notifications list --severity critical # Did this customer get their mail? corepanel notifications list --account john # Prove email works before something breaks corepanel notifications test corepanel notifications test --account john # Clear the badge corepanel notifications ack --all ``` See the [CLI reference](https://www.corepanel.net/docs/cli) for every flag.