Status pages for agencies and client-facing uptime
Give clients a clear place to check service status while your team manages incidents and alerts.
Why agencies publish status pages
Clients ask “is it down?” during incidents—a read-only page reduces repeated support pings.
Connected to real monitors
Public status pages reflect monitors you attach—uptime badges and active incidents when data exists.
Tags and monitor selection
Pick monitors manually or by tag intersection so each client sees the right subset.
Works with alert workflows
Status pages complement email, Telegram, and webhook alerts—they do not replace them.
Not a full client portal
SitePuls status pages are read-only snapshots—not billing, ticketing, or private dashboards.
Pair with multi-site monitoring
Many client URLs in one workspace; status pages surface the slice each audience needs.
When to skip a status page
Low-traffic marketing sites may need alerts only; SaaS and critical client stacks benefit most.
Where to start
Stabilize monitors and alerts first, then publish a status page for monitors clients should see.
What you can verify with SitePuls here
- Client-facing uptime visibility through public status pages.
- Incident communication support connected to monitoring.
- Works with uptime checks, alerts and status page settings.
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.
Practical monitoring guide
Example content below is illustrative — values are placeholders, not live customer data.
Client-facing status workflow
- Connect public status pages to the same monitors that drive alerts.
- Agree with the client what “degraded” vs “down” means for their users.
- Post updates when you investigate and when service recovers.
What incidents to communicate
- Confirmed downtime on customer-visible URLs or APIs.
- Planned maintenance with start and end windows when possible.
- SSL or domain issues that may affect the client’s brand trust.
Common mistakes
- No named owner for status updates during incidents.
- Updates only in private chat while clients refresh email repeatedly.
- Status page not linked from the client’s main site or support docs.
Frequently asked questions
Why use status pages for client sites?
Status pages give clients a clear place to see service status and reduce repeated support questions.
Should every client have a status page?
It depends on the client and service importance. Critical sites and SaaS clients benefit most.
Can status pages work with monitoring alerts?
Yes. Status pages are most useful when connected to uptime checks and incident workflows.
Can clients see each other's monitors?
Each published page lists only the monitors you attach—scope it per client or product.
Do status pages replace alerts?
No—alerts notify your team; status pages inform viewers who check proactively.
Authentication required?
Public status URLs are read-only without login for viewers.
CSV or SLA exports on public pages?
Detailed reports stay in signed-in monitor areas; public pages show operational snapshots.
How do I publish one?
Configure a status page in SitePuls, attach monitors or tags, and share the public URL.