Why Are Status Pages Necessary? — What to Communicate and Why at Each Phase of Incident Response

Service outages are inevitable. What sets companies apart is how they communicate with users when an outage occurs. A status page is the most basic and effective way to establish a systematic approach to this communication in advance.

In this article, we will first explain why status pages are necessary, and then detail what information is communicated and why during each phase of the process : incident detection, response, resolution, and RCA (root cause analysis).

The Need for a Status Page

What happens when an outage occurs if there is no status page?

Users become anxious because they can’t tell whether the issue lies with their own environment or with the service itself, so they contact support first. These inquiries flood the support team, which becomes overwhelmed with handling them. As a result, even the engineers who should be focusing on the critical recovery work end up spending their time responding to internal and external inquiries asking, “What’s the current status?” Since information is passed along by word of mouth, discrepancies arise, and ultimately, the only thing that remains is a sense of distrust: “That company doesn’t explain anything even when an outage occurs.”

The status page breaks this vicious cycle. Its key benefits are the following four points:

1. Serve as a single source of truth

By centralizing the distribution of outage information in a single location, you can ensure that everyone—both inside and outside the company—knows where to go to get the latest updates. This helps prevent discrepancies in information across multiple channels, such as social media, customer support, and sales.

2. Reduce the burden on support and development

Once users no longer worry that "Is this just my problem?", the total number of inquiries decreases. Even when inquiries do come in, we can simply direct them to the status page, which significantly reduces the initial response time for support and allows engineers to focus on resolving the issue.

3. Maintain and, if possible, strengthen trust

More than the outage itself, it is the lack of transparency—the fact that it was "hidden" or "not explained"—that severely erodes trust. Conversely, providing information promptly and honestly fosters trust that "this company is taking the issue seriously." Transparency transforms an outage into an opportunity to rebuild trust.

4. Serves as a record of accountability and SLAs

In the B2B and enterprise sectors in particular, records of outage occurrences, duration, and scope serve as the basis for verifying SLA compliance and processing service credits. The history on the status page functions as an official record that can be referenced later.

The key is to view the status page not as something you hastily put together after an outage occurs, but as a system that is integrated into your operational workflow from the outset. By establishing templates, designating the person responsible for updates, and defining the criteria for when to publish updates in advance, you’ll be able to act without hesitation when the time comes.

What to Communicate and Why, by Incident Response Phase

The nature of incident response changes over time. Since the information required varies by phase, it is important to be mindful of what should and should not be disclosed at each stage.

Phase 1: Issue Detection — First, communicate what you’ve noticed

What to serve

• Affected services and features (which ones)

• Symptoms observed by users (what is happening: e.g., "Unable to log in," "Slow loading")

• Time of detection

• Current status (e.g., Under investigation)

• Scheduled time for the next update

What not to include

• Possible cause ("Probably caused by...")

• Estimated time of restoration (not yet confirmed)

Why are we doing this?

In this phase, speed takes precedence over completeness. Even if the details aren’t clear, it’s valuable to communicate as quickly as possible that “we are aware of the issue and have begun addressing it.” The purpose of the initial announcement isn’t to provide an explanation, but to alleviate users’ anxiety—specifically, the worry that “Is this just my problem?”—and to prevent a flood of inquiries.

Ideally, the initial report should be issued within a few minutes, even if the cause is still unknown. A simple statement like, “We have confirmed that some users are currently experiencing login issues and are investigating the matter,” is sufficient. In fact, remaining silent in an attempt to issue a perfect report only after identifying the cause is what breeds the most distrust.

Furthermore, stating an unconfirmed cause as fact will require a correction later on, which will ultimately undermine credibility. Honestly stating that the matter is “under investigation” is, in the end, the most sincere approach.

Phase 2: In Progress — We’ll Keep You Updated on Our Progress and the Next Update

What to serve

• Regular progress updates (whether the cause has been identified and the status of the resolution)

• Update on the scope of impact (if it has expanded or narrowed)

• Temporary workaround for users (if available; e.g., "The XX feature can be replaced with YY")

• Scheduled time for the next update (always)

Why are we doing this?

The most important thing to avoid during the "handling" phase is silence. To users, a lack of updates signals that they are being "neglected" or that "the situation may be more serious." Even if there is no progress, simply continuing to post updates regularly—such as "We are still investigating the issue. We will provide an update at [time]"— serves as proof that you are actively addressing the situation.

As a general rule, updates should be issued at set intervals rather than only when there is progress. Determine the update frequency in advance based on the severity of the issue—for example, every 30 minutes for critical outages or every 1–2 hours for issues with limited impact. Furthermore, by always announcing the next update time in each update, users can rest assured that they don’t need to check the page until a specific time, which helps prevent repeated inquiries.

If we can provide a temporary workaround, we can directly alleviate users' pain points and further reduce the number of support inquiries.

Phase 3: After the initial response to the issue is complete — Clearly distinguish between "recovery" and "full resolution" when communicating

What to serve

• Declaration of recovery (or continued monitoring) and the time of such declaration

• What has returned to normal (when can users resume normal use)?

• If there are any lingering effects, please describe them (e.g., "It may take some time for data that was backed up to be reflected").

• A statement that the matter is under review and a declaration of final resolution

Why are we doing this?

The key here is to clearly distinguish between “hemostasis (temporary relief of symptoms)” and “complete resolution (addressing the root cause).” If you declare the issue “resolved” as soon as the service is up and running, you risk severely damaging trust if the problem recurs.

In practice, it is safest to divide the process into the following two stages.

1. Monitoring: Symptoms have subsided following a temporary fix, but we are currently monitoring the situation to ensure they do not recur. Please inform the customer: "We have implemented a fix, and service has now been restored. We are continuing to monitor the situation."

2. Resolved: The stage at which the issue is officially declared resolved after confirming that it has not recurred during a period of monitoring.

What users want to know most is, “Can I go back to using the service as usual?” That’s why it’s crucial to clearly communicate what has returned to normal and, if there are any lingering issues—such as data delays or backlogs that still need to be resolved—to be honest about those as well. The key to this phase is not to “declare victory prematurely.”

Phase 4: RCA (Root Cause Analysis) — Regaining Trust by Addressing "Why It Happened" and "Preventing Recurrence"

What to serve

• Incident Summary (What happened, when it occurred, and the scope of the impact)

• Timeline (Chronology of Detection, Response, and Recovery)

• Root Cause

• Details of the impact (number of affected users, affected features, and duration)

• Measures to Prevent Recurrence (Specific measures and, if possible, the planned implementation schedule)

Why are we doing this?

An RCA is not only the culmination of an incident response but also the best opportunity to restore—and even strengthen—trust. While real-time updates convey “what is happening right now,” an RCA explains “why it happened and what will be done to prevent it from happening again.”

Users—especially enterprise customers—are more concerned with whether the company truly understands the root cause and has systems in place to prevent a recurrence than they are with the outage itself. A sincere root cause analysis (RCA) demonstrates the technical organization’s maturity and sense of ownership, leading to the assessment that “although an outage occurred, this company is trustworthy.”

When writing an RCA, it is important to avoid placing blame on individuals. Rather than attributing the cause to “an employee’s mistake,” we should view it as “a systemic issue that allowed the mistake to reach production,” and focus on improving processes and systems rather than targeting individuals. This demonstrates integrity to external stakeholders while also fostering a culture within the company where we can openly discuss the root causes and drive meaningful improvements.

While you may omit some sensitive technical details when sharing information publicly, be sure to clearly communicate the three key points: "what happened," "why it happened," and "how to prevent it."

Summary: Principles Applicable to All Phases

Communication in each phase is based on the following common principles.

• Prioritize speed: For the initial report, speed is more important than perfection. Just include what you know.

• Don’t Stay Silent: Even if there’s no progress, post updates regularly and always include the “next update time.”

• Be honest: If something is still unclear, write "Under investigation." Avoid declaring the issue resolved or attributing blame too soon.

• Write in user-friendly language: Describe issues and their effects from the user’s perspective, rather than using internal jargon.

• Create templates: Prepare standard phrases and update criteria for each phase in advance so that you won’t be at a loss when the time comes.

A status page is not merely a "place to report outages." It is a mechanism designed to transform inevitable outages—rather than allowing them to erode trust—into opportunities to demonstrate it. The first step is to plan in advance what information to communicate and why, at every stage from detection to post-incident analysis.

At Incident Lake, we’re turning this process into a system

The "speed, transparency, and prevention of recurrence" mentioned in this article will inevitably falter when the time comes if they continue to rely solely on the efforts of individual staff members.

Incident Lake is a platform that centralizes incident response—from detection to resolution and post-incident analysis—all in one place.

• Centralized lifecycle management: Since you can track the status of incidents—from their occurrence through resolution and reopening—all in one place, everyone has access to the same up-to-date information at any given time.

• Automatic timeline logging: Since the history of the issue is recorded chronologically, there is no need to write status updates or RCA materials from scratch.

• SOP (Standard Operating Procedure) Checklist: Ensures that you can proceed without missing any steps—knowing exactly "what to do next" and "when the next update is due"—while preventing communication gaps and the reliance on individual expertise during the process.

• Streamlining RCA/Post-Mortem Processes: This makes it easier to identify root causes and develop preventive measures, helping you establish a culture of blame-free reflection.

• Knowledge Accumulation and Search: Reuse past troubleshooting insights to speed up the resolution of future issues.

• Analytics: Visualize MTTR and occurrence trends to improve the response process itself.

Once you’ve decided “what to communicate and why” on your status page, let’s use Incident Lake to systematize the behind-the-scenes processes that support those communications.