How to Monitor Service Uptime and Build Public Incident Pages with Better Stack

The invisible challenge of keeping systems online

Keeping a web application or an API running continuously is one of the toughest challenges for technology teams. When a system goes down, every minute of silence costs money, reputation, and user patience. In practice, the biggest problem is not just fixing the bug, but discovering it happened before your customers notice and complain on social media. That is why monitoring tools have evolved from technical luxuries into the central nervous system of any modern digital operation.

Historically, system administrators relied on home-grown scripts or complex tools that took weeks to configure just to send an alert email. Today, the ecosystem has evolved into cloud-based platforms focused on usability and rapid response times. Better Stack emerges as one of the leading exponents of this new generation, combining uptime checks, on-call scheduling, and public status pages into a clean, highly integrated interface.

In this technical article, we will explore how to build a complete monitoring strategy from scratch. You will learn how distributed probes work, how to configure intelligent alert rules to avoid midnight false alarms, and how to create a transparent communication channel to reassure your users when the worst happens.

How synthetic checks and telemetry actually work

The beating heart of any availability monitoring system is synthetic checks. In practice, this means automated robots scattered across the globe access your system at regular intervals to simulate real user behavior. If your homepage takes longer than acceptable to load or returns a server error, the system triggers an alert signal.

There are different levels of checks you can configure depending on your service criticality. A basic HTTP check merely tests if the web address responds with a success code, such as the famous 200 status. However, advanced checks can send JSON payloads, authenticate via tokens, and validate if specific text is present in the API response, ensuring that the database and auxiliary services are also operational.

Beyond external checks performed by robots, internal telemetry collects data from inside the server, such as RAM usage, CPU consumption, and disk space. When we combine the outside-in perspective with the inside-out view, we create a complete health map of the application, allowing us to anticipate bottlenecks before they cause a total service outage.

Configuring your first probe in Better Stack is a straightforward process, but it requires planning about what truly matters. Checking intervals that are too short, such as every ten seconds, can generate unnecessary alerts caused by momentary fluctuations in the network path between the cloud provider and your server. The ideal standard for most commercial web applications hovers around sixty seconds.

Another critical point is the geographic location of monitoring robots. If your audience is concentrated in Brazil, monitoring exclusively from European servers can introduce network latency that does not reflect your user's actual experience. Modern platforms let you select specific regions for probes, ensuring tests faithfully simulate your customer base traffic.

To illustrate how we can validate services programmatically, here is an example of a lightweight Node.js endpoint specifically designed to respond to internal and external health checks:

const http = require('http');
const os = require('os');

const server = http.createServer((req, res) => {
  if (req.url === '/healthz') {
    const freeMemory = os.freemem();
    const totalMemory = os.totalmem();
    const isMemoryCritical = (freeMemory / totalMemory) < 0.05;

    if (isMemoryCritical) {
      res.writeHead(500, { 'Content-Type': 'application/json' });
      res.end(JSON.stringify({ status: 'ERROR', reason: 'Low memory' }));
      return;
    }

    res.writeHead(200, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify({ status: 'OK', uptime: process.uptime() }));
  } else {
    res.writeHead(404, { 'Content-Type': 'text/plain' });
    res.end('Not Found');
  }
});

server.port = 3000;
server.listen(server.port, () => {
  console.log('Health check server running on port 3000');
});

This small script demonstrates how to expose a dedicated diagnostic route. If free memory drops below five percent, the endpoint returns an error code that Better Stack will immediately detect, changing the service status without requiring human intervention.

Escalation strategies and fighting false alarm fatigue

Receiving alerts in the middle of the night is one of the most stressful parts of software engineering work, especially when the alarm is a false positive caused by a temporary network spike. To preserve team sanity, it is essential to configure escalation policies and confirmation delays before triggering phone calls or urgent messages.

The golden rule in modern monitoring is to require a failure to be confirmed by at least two different geographic locations before waking up an on-call engineer. This eliminates noise generated by isolated internet routing glitches that self-correct within seconds, sparing the team from unnecessary sleep interruptions and maintaining confidence in incoming alerts.

Furthermore, on-call scheduling ensures that warnings are directed only to those assigned to the current shift. If the first notified engineer does not acknowledge the call within a specified timeframe, such as five minutes, the system automatically escalates the alert to the next responsible party or backup channel, ensuring incident response redundancy.

Building transparent public status pages

When a system goes down, the worst thing a company can do is hide behind a generic error page or ignore customer messages. Public status pages act as an official, automated communication channel, informing users in real time whether core services are operating normally or if scheduled maintenance is underway.

Better Stack allows you to build these pages visually and customizably, directly tying each system component to the monitoring probes we configured earlier. If the payment API goes down, the corresponding component on the public page automatically changes color, displaying a clear visual indicator to customers without requiring anyone to manually refresh the page.

Transparency builds long-term trust. Customers understand that any digital infrastructure is subject to sporadic failures; what truly irritates consumers is lack of communication and uncertainty. By publishing detailed updates on repair progress, a company demonstrates professionalism and operational control.

Automating incident updates and integrating channels

Although outage detection is automated, detailed communication about the root cause of an incident typically requires human intervention. Therefore, modern platforms make it easy to create message templates and integrate with corporate collaboration tools like Slack, Microsoft Teams, or custom webhooks.

When the engineering team identifies the source of the problem, they can update the incident status directly from the corporate chat using simple commands. This update is instantly reflected on the public status page and can trigger automated email or SMS notifications to registered subscribers who wish to track resolution in real time.

Below is a simple comparative table summarizing key approaches to managing customer communication during service disruptions:

Final thoughts on reliability and operational culture

Monitoring services and maintaining public incident pages goes far beyond installing third-party software; it is about cultivating a culture of transparency, continuous improvement, and respect for user time. When engineering and customer support work aligned with accurate availability data, a company becomes much more resilient in the face of inevitable surprises occurring in internet infrastructure.

Tools like Better Stack remove the technical friction required to implement high-level observability, allowing lean startups and large corporations alike to maintain rigorous reliability standards. The time invested in initially configuring smart probes and on-call routines always pays off during the first major incident avoided or communicated with exemplary clarity.