Public status pages: share availability without sharing your dashboard
Stakeholders want a green/red signal—not access to your entire workspace. SitePuls lets you expose chosen monitors on an optional public status page while incidents and configuration stay private.
Who uses public status pages
SaaS teams, agencies with SLAs, and anyone who needs a simple uptime narrative for customers or leadership.
What viewers see
High-level availability derived from your monitors—exact fields depend on configuration in the product.
What stays private
Your full monitor list, incident notes, and billing remain in the authenticated app.
Relation to internal incidents
Internal incident workflows continue as today; the status page is a filtered outward view.
Compared to third-party status vendors
SitePuls focuses on monitors you already run—no separate status product to sync.
Plans and availability
Availability of status pages may depend on your subscription—confirm in pricing and the in-app feature list.
What SitePuls does not do
Custom domains for status, subscriber email lists, or incident subscriptions may vary—use what the product exposes today.
Next steps
Configure monitors first, then enable or publish the status page from the status pages section of the app.
What you can verify with SitePuls here
- Public status URLs show an overall operational vs issues-detected badge derived from the monitors attached to that published page—not a full workspace export.
- Each listed monitor can show its display name or URL, optional tag badges from the monitor’s comma-separated tags field, a 7-day uptime percentage when data exists, and an UP/DOWN/PENDING badge from cached monitor state.
- A dedicated section lists active incidents for monitors on the page when the backing data exposes them; otherwise visitors see an empty-state message.
- Public pages are read-only customer snapshots; per-monitor CSV/SLA exports and emailed reports remain in the signed-in monitor report areas.
Where incident alerts can go
- Email addresses saved as alert contacts receive messages when incidents open or resolve (according to your notification settings).
- Telegram notifications via the SitePuls bot after you link a chat to an alert contact (including the bot /start flow for pending contacts).
- HTTPS webhooks that receive JSON with event type, monitor identifiers, status, timestamp, optional incident id, and a short message for generic integrations.
- Slack-compatible incoming-webhook formatting: alert contacts can use a dedicated mode so payloads match Slack-style incoming webhook expectations.
Illustrative sample — field names match the product; values are placeholders.
What visitors see on a public status page
- Page title and optional “last updated” timestamp from your workspace.
- Overall strip: operational vs issues, aligned with included monitors.
- Per-monitor rows: name or URL, optional tags, 7-day uptime %, UP / DOWN / PENDING badge.
- Active incidents table: status, monitor, short cause, started time.
- Resolved incidents: same columns plus resolved time when available.
FAQ
Do I need a separate product for status?
SitePuls includes status page capabilities tied to your monitors—see in-app options.
Can I white-label the domain?
Custom branding and domains depend on current product settings—check the app.
Is the page indexed by Google?
Public URLs may be crawlable; use robots settings appropriate for your communication strategy.
Per-company isolation?
Status configuration respects your company workspace boundaries.
Show incident history?
Depends on configuration—SitePuls aims at clarity for viewers without leaking internal detail.
Mobile friendly?
Public status layouts are designed for readers on common browsers.
Link from marketing site?
Yes—publish the public URL where customers expect status information.
Where do I configure it?
Signed-in users manage status pages from the SitePuls status pages area.