Better Stack (Better Uptime) Guide: Incident Management for Modern Teams

Incident management has a scaling problem. The tools designed for enterprises — PagerDuty, OpsGenie with full configuration — are powerful but expensive and complex to set up correctly. The tools designed for small projects — basic uptime checkers — lack the on-call scheduling and escalation workflows that real teams need when things go wrong at 3 AM.

Better Stack, formerly known as Better Uptime, sits in the middle of that spectrum. It combines uptime monitoring, incident management, on-call scheduling, and status pages into a single platform designed to be practical for teams of 2 to 50 engineers. This guide covers how to use it effectively.

What Better Stack Is (and What Changed)

Better Uptime launched as a monitoring service with unusually good incident management features for its price point. In 2022, it rebranded as Better Stack after acquiring Logtail (a log management product), positioning itself as a broader observability platform.

For monitoring and incident management purposes, the core product is largely the same — the incident management, on-call, and status page features that made Better Uptime popular are intact. The Logtail integration adds log-based alerting for teams who want it.

The free tier includes:

• 10 monitors with 3-minute check intervals
• 1 on-call calendar
• Basic status pages
• Email and Slack alerts

Paid plans start around $20/month and add more monitors, faster check intervals (30 seconds), unlimited on-call calendars, and more advanced escalation features.

Core Monitoring Setup

Adding Monitors

The monitoring setup is similar to other tools: URL, check type, and interval. Better Stack adds a few features that differentiate it:

Screenshot on failure — When a monitor goes down, Better Stack takes a screenshot of what the page looks like at failure time. This is genuinely useful for debugging — you can see whether the site shows a 500 error page, a blank screen, or a maintenance notice, without having to reproduce the failure.

Multi-location checks — Better Stack checks from multiple geographic regions by default and only alerts when multiple locations confirm the failure. This eliminates false positives from single-region network issues.

Automatic incident creation — Every monitor failure automatically creates an incident. This isn't just an alert; it's a tracked event with a timeline, assignee, status updates, and resolution time. This is the key architectural difference from simpler monitoring tools.

Monitor Types

Better Stack supports HTTP, keyword, ping, port, and heartbeat monitors — the same categories as most monitoring tools. The heartbeat implementation deserves specific mention.

Heartbeat monitoring is configured with an expected check-in period. Your job, cron task, or background worker hits a provided URL after each successful run. If Better Stack doesn't receive a heartbeat within the window, it creates an incident. This is more reliable than trying to monitor cron jobs through external HTTP checks.

Incident Management: The Core Differentiator

Where Better Stack diverges meaningfully from basic monitoring tools is in incident management. Most uptime checkers send an alert and stop there. Better Stack treats every alert as the start of an incident lifecycle.

Incident Lifecycle

1. Monitor detects failure → Incident created automatically
2. On-call responder receives alert → Via call, SMS, push, Slack, or email
3. Responder acknowledges → Incident moves to "acknowledged" state; escalation stops
4. Work happens → Optional: update incident status, add notes
5. Monitor recovers OR Responder marks resolved → Incident closed
6. Post-incident data → Response time, resolution time, and timeline saved for later review

Every incident has a permanent record. After three months, you can look at your incident history and understand which services fail most often, how long incidents typically take to resolve, and whether specific times or deployments correlate with failures.

Incident Severity

You can configure alert severity per monitor. A non-critical internal dashboard going down might generate a low-severity incident that triggers a Slack message. Your payment processing API going down generates a critical incident that calls your on-call engineer immediately.

Severity also affects escalation behavior — higher severity incidents escalate faster and more aggressively.

On-Call Scheduling

On-call scheduling is where Better Stack competes most directly with PagerDuty and OpsGenie, and where it wins on simplicity for smaller teams.

Creating an On-Call Calendar

Better Stack uses a calendar-based interface for on-call scheduling. You define:

Rotation type — Daily, weekly, or custom period. Most teams start with weekly rotations.

Team members — Who's in the rotation. Each person needs a verified phone number for call/SMS alerts.

Time restrictions — Optionally restrict on-call hours. A "business hours" calendar (9 AM–6 PM) paired with a "nights and weekends" calendar with different participants gives you full coverage with appropriate ownership.

Overrides — Any team member can claim or release on-call coverage for specific time periods. Going on vacation? Override your scheduled slot and assign it to a colleague.

The calendar view makes it easy to see who's on-call at any given time, which matters when an incident happens and you're trying to understand the response.

Escalation Policies

An escalation policy defines what happens when the primary on-call person doesn't acknowledge an incident within a set time window.

A typical escalation policy:

1. Alert on-call engineer via push notification (0 minutes)
2. If not acknowledged in 5 minutes: call on-call engineer's phone
3. If not acknowledged in 10 minutes: alert secondary on-call
4. If not acknowledged in 15 minutes: alert engineering manager

Better Stack's escalation policies are simpler than PagerDuty's but cover the cases most teams actually need. You won't find multi-tier conditional logic here, but you will find a working escalation policy you can configure in 10 minutes.

Phone Calls and SMS

When an on-call alert escalates to a phone call, Better Stack calls the engineer and reads the incident details aloud. They can press a key to acknowledge directly from the call. This is the behavior that makes on-call tooling actually work — email during a high-severity incident is noise; a phone call wakes someone up.

SMS alerts are the middle ground: persistent enough to notice, not as demanding as a call.

Heartbeat Monitoring in Practice

Heartbeat monitoring deserves its own section because it's underused relative to how useful it is.

The problem it solves: Traditional monitoring checks whether an endpoint responds. It can't detect jobs that silently stop running. If your nightly database backup stops executing, UptimeRobot won't notice — the backup service isn't returning errors, it just isn't running.

The Better Stack solution: Create a heartbeat monitor with a 24-hour window. Add a single HTTP GET call to the provided heartbeat URL at the end of your backup job:

# At the end of your backup script
curl -s https://betterstack.com/api/v1/heartbeat/YOUR_TOKEN > /dev/null

If the backup runs successfully, the heartbeat fires, and all is well. If the job fails, hangs, or stops running entirely, Better Stack creates an incident after 24 hours of silence.

Common heartbeat use cases:

• Nightly database backups
• Scheduled report generation
• Email queue processing
• Data sync jobs between systems
• Certificate renewal automation (Let's Encrypt)

Each of these is a job that needs to run and often doesn't have obvious external symptoms when it stops.

Status Pages

Better Stack's status page feature is more polished than most competitors. You get:

Component groups — Organize your status page into logical sections customers recognize ("API", "Dashboard", "Authentication") rather than internal service names.

Automatic incident display — When a monitor creates an incident, it can automatically appear on your status page. You control whether this is automatic or requires manual selection.

Subscriber notifications — Customers can subscribe to status page updates via email. They get notified when incidents open and when they're resolved.

Custom domains — Available on paid plans. status.yourcompany.com looks significantly more professional than a shared subdomain.

Historical uptime display — The last 90 days of uptime per component, shown as a bar chart. Customers can see your reliability track record, which builds trust when everything is working and provides context when something goes down.

Incident Communication

During incidents, you post updates through the status page interface. Each update gets a timestamp and appears in the incident timeline. Good incident updates:

• Acknowledge the issue immediately (even before you know the cause)
• Provide updates every 20-30 minutes even if there's nothing new
• Explain what's affected and what workarounds exist
• Give an estimated resolution time when you have one
• Post a clear resolution message when the incident closes

Status page communication isn't technical documentation — it's customer-facing communication that needs to be clear to non-technical readers.

Better Stack vs. PagerDuty: A Direct Comparison

Teams evaluating incident management tools often compare these two directly. The comparison is real, and both have genuine advantages.

Where Better Stack Wins

Price — Better Stack's team plan is dramatically cheaper than PagerDuty's for comparable features. A team of five engineers will pay hundreds less per month.

Setup time — You can configure on-call schedules, escalation policies, and a status page in an afternoon. PagerDuty has more configuration depth, which also means more time to get right.

Integrated monitoring — You don't need a separate monitoring tool. Better Stack handles both monitoring and incident management in one place.

Status pages — Better Stack's status pages are more polished out of the box than PagerDuty's incident communication features.

Where PagerDuty Wins

Advanced escalation logic — PagerDuty's escalation policies support conditional logic, service-level routing, and complex multi-tier escalation scenarios.

Ecosystem integrations — PagerDuty integrates with a longer list of monitoring tools, ITSM systems, and cloud providers.

Analytics — PagerDuty's reporting and analytics on incident patterns, MTTR, and team performance is more sophisticated.

Enterprise compliance — PagerDuty has longer track record for SOC 2, HIPAA, and enterprise procurement requirements.

The practical guidance: If you're a team under 50 engineers without complex organizational structure, Better Stack will cover your needs at a fraction of the cost. If you're a larger organization with multiple teams, complex on-call hierarchies, or deep integration requirements, PagerDuty is probably worth the investment.

Integrating Better Stack with Your Tools

Better Stack integrates with most common tooling through either native integrations or webhooks.

Monitoring source integrations — You can forward alerts from Datadog, Grafana, CloudWatch, or other monitoring tools into Better Stack for unified incident management, even if you don't use Better Stack's own monitors.

Communication integrations — Slack, Microsoft Teams, and email for team notifications.

Issue trackers — When a Jira integration is enabled, incidents can automatically create Jira tickets. Useful for post-incident tracking without manual data entry.

Webhooks — Any tool that accepts webhooks can receive Better Stack incident events: opened, acknowledged, resolved, and escalated.

Practical Setup Recommendations

Start with your five most critical monitors. Don't spend the first day configuring 50 monitors. Get the most important services wired up with escalation policies, then expand.

Test your on-call configuration. Before relying on on-call during an actual incident, trigger a test alert and verify the call reaches your phone. Discover configuration problems during low-stakes testing.

Set up heartbeat monitors for every scheduled job. If it has a cron schedule, it should have a heartbeat.

Publish your status page before you need it. Link it from your documentation and application UI ahead of time. Finding out your status page URL during an incident is not the time.

Write your escalation policy before you need it. "Who do we call if the first person doesn't answer?" is not a question to answer mid-incident.

Functional Testing Complements Monitoring

Better Stack monitors whether your services are up and responding. It doesn't verify whether your application is functionally correct — whether users can actually complete their workflows.

A server can return 200 OK while the login form is broken, the payment page throws JavaScript errors, or the search functionality returns empty results. Uptime monitoring won't catch any of that.

HelpMeTest runs real browser-based functional tests against your application on a schedule, verifying that users can actually accomplish their goals. When functional tests fail, you can route those alerts through Better Stack for the same incident management workflow you use for infrastructure failures.

The combination — infrastructure monitoring with Better Stack, functional testing with HelpMeTest — gives you comprehensive coverage from the server level down to user-facing application behavior.

Conclusion

Better Stack fills a real gap in the monitoring market: incident management that's sophisticated enough to handle real on-call workflows, but approachable enough for teams without a dedicated SRE function.

The free tier is useful for small projects. The paid plans are priced reasonably for teams that need proper on-call scheduling and escalation policies. And the status page feature is one of the better implementations available for any price.

If you're currently using a basic uptime checker and manually routing alerts through Slack without any escalation structure, Better Stack is worth evaluating. The upgrade from "Slack message when something breaks" to "on-call rotation with escalation policies and a customer status page" takes an afternoon to configure and makes a real operational difference.