Services & Updates

Services

A service is one row on your status page. It is backed by a monitor, but presented in your users' language rather than your infrastructure's.

Adding a service

1. Open the status page and go to Services.
2. Click New Service.
3. Fill in:
   • Service name — what visitors see. Use "Website" or "API", not "web-prod-03".
   • Service URL — optional link, so visitors can go straight to the thing.
   • Monitor type — Server, Site, Ping, Port or Heartbeat.
   • Monitor — which of your monitors of that type backs this service.
   • Description — optional, shown under the service name.
4. Save.

INFO

Blacklist and Workstation monitors cannot be added to a status page. Blacklist reputation and staff laptops are not things your customers need to see.

Several services can point at the same monitor if that is genuinely how your users think about it, and one monitor's failure will then show against each.

What visitors see

Each service shows its current status and a 90-day uptime bar. The status comes directly from the monitor's state, which your triggers determine:

Monitor status	Shown as
Up	Operational
Degraded	Service may be impacted
Down	Problems detected
Maintenance	Maintenance in progress
Unknown	Status unknown

All of that wording is customisable — see Appearance & Text.

WARNING

Check what your triggers classify as Down before publishing a page. A response-time trigger with an aggressive threshold and Degraded impact will tell the world your service is impaired every time it has a slow minute.

Updates

An update is a post on your status page — an incident notice, a progress note, a resolution, or a scheduled maintenance announcement.

Publishing an update

1. Open the status page and go to Updates.
2. Click New Update.
3. Fill in:
   • Title — a short summary. "Elevated API error rates", not "Incident".
   • Description — what is happening, what you know, what you are doing.
   • Severity — Info, Warning, High, Resolved or Maintenance.
   • Time — when this applies, in your account timezone. Defaults to now.
4. Save.

Severities

Severity	Use for
Info	Context that isn't a problem — "we're aware of reports, investigating"
Warning	Partial impact — some users, some features, degraded performance
High	Major impact — the service is down or unusable
Resolved	The incident is over
Maintenance	Planned work, ideally posted in advance

Notifying subscribers

Updates can be emailed to your subscribers. Each update is sent once and only once — republishing or editing does not re-send it.

Automatic updates

With Auto updates on (under Settings → General), Pingniner publishes updates itself when a service changes state: one when it goes down, one when it recovers, and optionally one when it becomes degraded.

The titles and messages are templates you control, and support a {service} placeholder that is replaced with the service name. Edit them under Appearance & Text.

Automatic and manual updates coexist. A common pattern is to let auto-updates announce the outage immediately, then post a manual update with detail once you know what is happening.

Writing good updates

• Post early. "We're investigating reports of errors" within five minutes beats a perfect explanation an hour later.
• Say what users can't do, not what broke. "Checkout is failing" is more useful than "Redis cluster failover".
• Give a next-update time. "Next update in 30 minutes" stops people refreshing.
• Always post a Resolved. An incident with no resolution reads as ongoing forever.
• Avoid blame and jargon. The page is public, and it will be screenshotted.