Notifications in the AdminCP

Open AdminCP → System → Notifications (/admin/core/system/notifications) to see how notifications are doing, decide what members get by default, and tidy up when you need to.

PermissionsCopy Anchor Link

The screen uses the core notifications staff permission module:

Grant them in Staff → Administrators (/admin/core/staff/admins). See Staff permissions.

ActivityCopy Anchor Link

Four numbers for the last 24 hours, 7 days or 30 days, each compared with the period before it and drawn as a small trend line:

• Emails delivered - notification emails that went out (test emails don't count).
• Failure rate - failed emails out of everything that was attempted.
• Events published - notifications plugins and core published.
• Emails skipped - emails that were due but not sent, for example because the member turned email off or the notification was already read.

Days and hours follow the site's time zone, so "today" means the same thing to everyone on the screen.

Hover a trend line - or tap it on a phone - to see one day (or one hour in the 24 hour view) and its count, like "Sun, Oct 4 · 3 events published". The failure rate shows how many emails failed out of how many were tried. With the chart focused, the arrow keys step through the same points.

If notifications are paused, a banner at the top says so.

Notification typesCopy Anchor Link

Every registered type, grouped by plugin. Each row shows what members get today at a glance - notification list, push and email - and opens to change it:

• Enabled by default - members get it unless they turn it off.
• Not enabled by default - members get it only after turning it on.
• Disabled - nobody gets it on that channel and the option disappears from members' settings.

Changes save as you click and apply to members who never chose for themselves. Members' own choices still win, unless the type is locked. See How core decides.

Mandatory types always show in the notification list and are always locked. Switching email back to Enabled by default keeps the frequency (immediate, daily or weekly) the type had before.

Reset all members to defaultsCopy Anchor Link

The button next to Notification types wipes every member's own choices - list, push and email choices - so everyone follows the defaults on this page again. The confirmation says how many members picked their own settings. It can't be undone.

A member's time zone is part of their account, so a reset keeps it.

SettingsCopy Anchor Link

The Settings button opens a sheet with tools and the danger zone. Only staff with the can_manage permission see it.

There is no installation-wide email switch or hourly limit: email is decided per type, in Notification types. Retention and worker batch sizes are deployment settings, set in your API config - see Queue and scale → Configuration. The sheet shows the current retention period at the bottom.

ToolsCopy Anchor Link

• Send a test email to me queues a sample notification email to your own address. It can't be sent to anyone else. It only shows when an email adapter is configured.

Old notifications are removed every night at 02:00 by the notifications-cleanup cron.

Danger zoneCopy Anchor Link

Each action affects every member at once and asks before it runs:

Deleting keeps types, preferences, settings and email history. It can't be undone.

Admin APICopy Anchor Link

All routes live under /api/@vitnode/core/admin/notifications:

GET /stats takes range (24h, 7d or 30d) and timeZone (an IANA name, like Europe/Warsaw). PUT /types/{type} merges what you send into the stored policy:

{
  "allowInApp": true,
  "inApp": false,
  "allowPush": true,
  "allowEmail": true,
  "email": "daily",
  "memberCanEdit": false
}

The deliveries list, retry and unread count repair have no buttons on this screen any more - the routes stay for scripts and for the debug panel.

RelatedCopy Anchor Link