Status Page Development for SaaS: Monitoring and Notifications

A status page that doesn't lie: where incidents get lost

Some services degrade — response time grows, background jobs stall, some users cannot log in.

The on-call engineer already sees this in the graphs, but there is still no public notification: it will appear in half an hour, when support collects the first requests and someone manually updates the page.

A gap yawns between “we know” and “the client knows,” and it is exactly there that distrust is born.

A typical cause is that the status page lives separately from availability monitoring. Checks run from inside the same perimeter as the service itself, so an external entry point failure or problems on the client side are not reflected in them.

Add manual publication mode: until an incident is confirmed by the on-call engineer, no one is notified about it, and confirmation can easily be postponed until morning.

Incidents get lost at shift handovers. A check fired, a notification went to the on-call chat — but not to the public channel; the context was not handed over, and the next engineer investigates from scratch.

Clients learn about the failure from their own errors and write to support before we acknowledge the problem. Failure visibility during such hours drops to zero, even though it is needed precisely when the load on the first line is highest.

A properly assembled status page is not a showcase, but part of the notification perimeter: external checks, automatic status transitions based on error and latency thresholds, and notifications to clients before they notice the failure themselves. We explain how this is covered.

Implementation effects: response time and request flow

The effect of a status page is visible not in the interface, but in two values: how quickly a client learns about a failure and how many requests reach support at the same time.

We take both before launch — from the request log and on-call records — and repeat them after a month of operation, so the comparison is based on the same data rather than on impressions.

The page structure is not invented from scratch: components, incident templates, and subscriptions follow what Atlassian Statuspage established, so the client does not need to be explained how to read the status.

Acceptance is based on a checklist, not on the page’s appearance:

• notification is generated automatically when a check fires, without a manual on-call step;
• incident closure is mandatory, otherwise the status will not return to a working state;
• subscription delivers updates by email and messenger, including unsubscribe;
• the publication procedure is fixed in the on-call regulations and message templates.

The main result is that an entire class of failures that used to be learned about from clients disappears. The first signal comes from monitoring, not from a message asking “is everything working for you?”, and the path from failure to public notification takes minutes.

Status page formats: public, private, and internal

A public status page is the perimeter seen by clients and the support service. A private status page is opened by invitation or by signing in to an account: it shows a specific customer’s components and history for their segment.

The internal on-call dashboard is a team working tool, and it shows noticeably more than is acceptable to expose externally.

The format choice is determined not by layout convenience, but by what data can be disclosed and who makes the incident decision. Below are three options that are actually chosen between.

The public and internal perimeters do not replace each other: confirmed facts go outward, while raw metrics and the progress of work go inward.

Notification subscriptions are configured separately for each perimeter — clients receive messages about their components, and the on-call engineer receives them based on trigger thresholds, so alerts are not duplicated into a common channel.

Implementation stages: from service discovery to handover of regulations

Monitoring implementation begins not with configuring notifications, but with an inventory: which services support the product, who is responsible for them, and what each depends on.

Without this picture, a status page turns into a list of buttons — during a failure, it is unclear what exactly is affected and whom to escalate. That is why our first stages are about the diagram, not the tools.

1. Inventory of services and dependencies — we collect components, external integrations, queues, and storage, and mark owners and likely failure points.
2. Service and dependency diagram — we build a relationship graph: what the failure of which node affects and how it manifests in user scenarios.
3. Check setup — we define probe types for each component, trigger thresholds, and intervals so as not to catch noise from brief deviations.
4. Notification regulations — we assign who receives a notification and in what window, which events are published on the page, and how the status is updated during an incident.
5. Public page assembly — we expose only components meaningful to the client and link them to the internal diagram so that the status matches reality.
6. Test on a training incident — we simulate a failure and run the entire path: trigger, notification, publication, closure. It shows where time is lost.
7. Handover — we provide access, documentation, and regulations; the on-call shift works from them without our involvement.

Implementation artifacts: service diagrams, templates, and regulations

Implementing a status page ends not with publishing the first page, but with handing over a document set.

Without it, in a month no one will remember why some services are separated into different components, who has the right to remove the banner, and with what wording to open the first incident update. The set is assembled during the work and remains with the customer’s team.

• Service map and component descriptions — which external dependencies the client sees, how they are connected, and which component is considered affected when an adjacent service fails. The map is updated with every new integration, otherwise the status starts showing non-existent connections.
• Notification templates — prepared templates for four states: planned maintenance, degradation, partial failure, and full failure. Each has three parts: what is affected, what the user should do, and when to expect the next update.
• On-call regulations — who confirms an incident first, during which hours, how they hand over the shift, and which timestamp is used to measure response time.
• Escalation procedure — escalation levels from the on-call engineer to the service owner and technical lead, with signs by which the level is raised without waiting.
• Incident documentation — a unified recording format: detection time, affected components, published updates, cause, and remediation actions. It is used to reconstruct the timeline and revise templates.
• Status access rules — roles with different permissions: read, publish updates, manage components, configure subscriptions. Permissions are granted to a group rather than individually, so the on-call engineer does not end up without access on weekends.
• On-call engineer instructions — a step-by-step procedure from receiving the signal to closing the incident: where to view service status, which template to choose, and what to check before publishing.

The set is stored next to the page code and updated together with it — then the status remains a reliable source rather than an archive of past releases.

Case study: how incident notification time was reduced

The client is a SaaS service with a high request rate: during peak windows there are several thousand active sessions, and degradation of an external dependency immediately turns into a stream of emails to support.

Before the project, failures were learned about from complaints — on average 12 minutes after they began, and another 12 minutes went into manual notifications.

The on-call load grew along with incident frequency: more than a hundred manual messages per week — to chat, email, and the status page. Incident history was kept in chat threads, and the timeline for analysis was reconstructed manually.

What was changed

We separated the perimeters: the status page, control panel, check service, and mailing live separately from the main application and remain available when the product itself is unavailable.

External checks on UptimeRobot and internal metrics are consolidated into a single layer that opens and closes incidents automatically according to rules: confirmation — update — recovery.

Automatic messages go to client channels immediately after a status change, with templates and tone set in advance. The incident log stores timestamps, cause, and duration — analyses are assembled from facts, not from the on-call engineer’s memory.

Results: notification time decreased from 12 minutes to 80 seconds, about 90% of publications go out automatically, and manual notifications are almost gone. When a failure recurred, clients saw the status before the first request reached support.

How does a client-facing status page differ from the on-call dashboard?

The public status page and the on-call dashboard rely on the same component model but solve different tasks: the first reduces the flow of identical support requests, while the second speeds up failure localization. State and user impact go outward, while metrics, logs, and connections between services go inward.

The client sees a list of components, their state, incident history, and subscription to updates.

We keep wording at the level of impact: “increased response time in the customer portal” instead of “database node degradation.” Names of internal services and node addresses do not appear in public text — they can be used to reconstruct the architecture.

The on-call dashboard works with the same component map, but alongside it are graphs, monitoring system events, and alert binding to the service.

The on-call engineer sees what exactly has degraded and whom it affects, and prepares a draft publication without switching between tools.

Access levels are separated: the client has only view and subscription, the on-call engineer has state editing, and the shift lead has publication confirmation and escalation. Every change goes into the log: you can see who raised or cleared an incident and when.

Notification granularity also differs: the client subscribes to specific components and channels and receives a message after the incident is confirmed — this filters out notifications for brief spikes.

Planned maintenance goes out in advance using a separate template and is not mixed with emergency ones.

Technical objections: false signals and the closed perimeter

Doubts at the start are almost always the same — not about the page’s appearance, but about its behavior during a real outage.

What if the communication channel through which the page receives data fails?

We place the page outside the main perimeter and keep a static snapshot of the last state: if data collection is unavailable, the visitor sees the update time rather than an empty screen.

Will we not expose the internal system design?

Publication remains a closed perimeter: we expose only externally observable symptoms and service impact — what is unavailable and for whom. Names of internal components and failure causes remain in the internal analysis.

Can incident history be updated retroactively?

The timeline is kept as a log: an entry is recorded with a timestamp, and a clarification is added as a new line, not by overwriting the old one. The postmortem remains verifiable.

What happens when you hand the project over to another team?

Supporting a status page means on-call regulations, a check catalog, message templates, and access. We hand them over through documentation, not “in the engineer’s head.”

Let’s discuss the task: where implementation begins

We start the conversation with service discovery: what already emits metrics, which external dependencies are critical, and which teams should receive a notification during degradation.

This determines the set of checks and the component model of the public status page — without such discovery, any estimate will be a guess.

What the first discovery will include:

• service and dependency map: what we consider degradation, what is planned maintenance, and what we do not expose externally at all;
• list of checks and thresholds — availability of services and their interfaces, response time, error rate, and freshness of processing queues;
• notification scenarios: who receives a message, for which event, and in which channel, and how time-based escalation works;
• page component structure and incident publication rules: what the client sees and what remains in the internal perimeter;
• access model and role separation — who prepares the entry, who confirms publication, and how change auditing is performed;
• rollback modes: how quickly we return the configuration to the previous state if an update fails;
• list of affected integrations so that the transition goes without downtime for users.

On your side, we will need a list of services, current monitoring diagrams, and the contact of the person responsible for infrastructure.

After discovery, we return with an estimate and work plan: stages, scope of checks, what we cover ourselves, and at which step we bring in your team.