Reports & Subscribers

Visitor issue reports

You can let visitors tell you something is broken directly from the status page. This catches the failures monitoring misses — a broken checkout that still returns 200 OK, a regional problem, a bug in one browser.

Turning it on

1. Open the status page and go to Settings.
2. In the User Reports section, enable Allow visitors to report issues.
3. Under Notify, choose which of your users should hear about incoming reports.
4. Save.

A "Report an issue" form appears on the public page, asking for the affected service and a description.

INFO

Notifications about reports are batched, not sent one per report. If something breaks and thirty people report it, you get a digest rather than thirty emails.

Handling reports

Reports arrive on the status page's Reports tab, showing when it was reported, the service, the description, the reporter's email and their IP address.

Each report has a status:

Status	Meaning
New	Not yet looked at
Reviewed	You have seen it and it is genuine or being handled
Dismissed	Not an issue — a mistake, a duplicate or spam

Available actions:

• Post update — jump straight to publishing an update about it
• Mark reviewed
• Dismiss
• Delete

All of these work in bulk, which matters when one outage generates a flood.

A note on abuse

The form is public and unauthenticated. Reports capture the submitter's IP, and you can dismiss or delete in bulk. If a page attracts persistent spam, turn reports off in settings.

Subscribers

Visitors can subscribe to email updates so they hear about incidents without watching the page.

How subscribing works

1. A visitor enters their email address on the status page.
2. Pingniner sends a confirmation email.
3. They click the link to confirm.
4. From then on they receive the updates you publish.

This is double opt-in — an address that never confirms is never emailed again beyond that one confirmation. That protects your sending reputation and means nobody can subscribe someone else.

Managing subscribers

The Subscribers tab lists everyone, with their email, whether they have confirmed, when they subscribed, when they were last notified, whether they have unsubscribed, and the IP they subscribed from.

Filters let you show only confirmed subscribers, only those awaiting confirmation, or hide unsubscribed ones.

Two actions are available:

• Resend confirmation — for someone who lost or never received the first email
• Delete — remove the subscriber entirely

The list is read-only otherwise. You cannot add subscribers manually, by design: everyone on it asked to be there.

What subscribers receive

Only the updates you publish, whether posted manually or generated by auto-updates. Each update is sent once.

Subscribers do not receive your internal alerts or uptime reports — those are for your team.

Unsubscribing

Every email has an unsubscribe link, and supports one-click unsubscribe in mail clients that offer it. It takes effect immediately and needs no login.

Unsubscribed addresses stay in the list marked as unsubscribed, rather than being deleted, so they are not accidentally re-added.

Best Practices

• Turn on visitor reports if you have real users. They will find things monitoring cannot see.
• Route report notifications to someone who acts on them, not a shared inbox nobody reads.
• Post an update when reports spike, even before you know the cause. It stops the reports and reassures people.
• Publish sparingly. Subscribers opted into incident news, not a changelog. An update for every minor blip trains people to unsubscribe.