How to Configure Better Stack Escalation Policies for On-Call Alerts

An uptime monitor can detect a failure correctly and still produce a poor incident response if nobody owns the alert, the first responder is unavailable, or every event pages the whole team immediately. Better Stack escalation policies separate who gets alerted and in what order from the monitor that detects the problem.

This tutorial builds a simple production-oriented pattern: page the current primary on-call responder, wait an interval aligned with your response objective, then notify a backup schedule or team if the incident remains unacknowledged. It also explains where severities fit, how to attach the policy to monitors, and how to validate routing without manufacturing a production outage.

Last verified: September 10, 2026. Escalation UI labels, integrations, and product capabilities can evolve; verify the linked Better Stack documentation before applying a workflow in production.

What You'll Accomplish

You will create an escalation design with:

1. a clearly named primary on-call destination;
2. a backup destination for unacknowledged incidents;
3. a deliberate delay between escalation steps;
4. optional reusable severity behavior;
5. a policy assigned to the correct monitor or monitors; and
6. a safe verification process using a test incident or non-production resource.

Prerequisites

Before editing policies, prepare:

• a Better Stack workspace with access to escalation policies;
• at least one primary responder or current on-call schedule;
• a second responder, backup schedule, or team for fallback;
• one monitor or integration to which the policy will eventually be assigned; and
• a test-safe notification path.

If you do not yet have an on-call schedule, create and verify that first. Better Stack's current backup-schedule documentation uses separate Primary/L1 and Secondary/L2 schedules, which makes responsibility easier to understand than relying on a long list of individual people.

Quick Answer

Open Escalation policies → Create escalation policy, give the policy a purpose-specific name, and make the first step alert the primary/current on-call responder. Add a second escalation step that waits for a deliberate interval before alerting a backup schedule or team if nobody has acknowledged the incident. Save the policy, then assign it to the relevant monitor under that monitor's on-call/escalation configuration. Do not assume a newly created policy is active: Better Stack requires explicit assignment. For validation, use a test policy/recipient and a manual incident or non-production monitor, then confirm that notification order, acknowledgement behavior, and fallback match the design.

Step 1: Design the Escalation Before Configuring It

Start on paper with one sentence:

"If this incident is not acknowledged by the primary responder within our response window, who should be next?"

For many teams, a maintainable first policy is:

Primary on-call → delay → Backup on-call

A larger organization may later add service ownership, metadata routing, business-hours branches, Slack/Teams, instructions, or a fallback policy. Do not add those features merely because they exist.

The escalation tree should mirror actual human responsibility. If the second step alerts a team that nobody believes owns the service, the configuration is technically valid but operationally useless.

Choose the delay from your response objective

Better Stack's documentation shows a backup example with a 15-minute delay. Treat that as an example, not a universal recommendation.

Your delay should consider:

• incident severity;
• expected acknowledgement time;
• time of day;
• whether the primary responder has reliable push/phone delivery;
• the cost of paging the backup too early; and
• the cost of waiting too long.

For a severe customer-facing outage, a long delay may be unacceptable. For a low-urgency issue, immediate multi-person paging may create unnecessary fatigue.

Step 2: Create the Escalation Policy

The current Better Stack workflow is:

1. Go to Escalation policies.
2. Select Create escalation policy.
3. Give the policy a descriptive name.
4. Configure its escalation steps.
5. Select Create escalation policy.

Use a name that communicates ownership and intent, such as:

Customer API - primary then backup

Avoid names such as Default, Policy 2, or Critical. Those names become ambiguous when several teams create similar policies.

Configure the first step

For the first step, choose the current primary on-call schedule or intended primary responder.

Better Stack's escalation documentation currently allows destinations including specific team members, the current on-call team, Slack or Microsoft Teams integrations, Zapier, and webhooks.

For a human-response policy, use the destination that represents accountable ownership. A Slack channel can be useful context, but a channel with no assigned responder is not the same as an on-call person.

Step 3: Add a Backup Escalation Step

Add another escalation step using the UI's Escalate & alert / delay behavior, then select the backup schedule or responder.

The pattern becomes:

1. alert Primary/L1 immediately;
2. wait the selected interval;
3. if the incident is still unacknowledged, alert Secondary/L2.

Better Stack's current backup on-call guide explicitly documents this approach with two schedules and a delayed second step.

What acknowledgement changes

The escalation policy is intended to keep progressing until the incident is acknowledged. That is why the handoff matters: the delay is not merely a second notification timer; it is part of an ownership model.

Responders should know what acknowledgement means operationally. It should normally mean "I own the incident and am investigating," not "I saw a notification."

If your team acknowledges incidents automatically without a human taking ownership, escalation can stop while the problem remains unattended.

Step 4: Understand Repeat and Fallback Behavior

Better Stack's current policy API exposes concepts including:

• repeat_count — how many times the whole policy can repeat if nobody acknowledges;
• repeat_delay — the delay between repeats; and
• fallback_policy_id — another policy to escalate to after the current policy exhausts its steps/repeats.

These capabilities are useful, but they can create alert storms if configured aggressively.

For a first policy:

• do not repeat the entire policy many times merely to increase urgency;
• prefer a clear backup owner over repeated notifications to the same unavailable person;
• use a fallback policy only when there is a real organizational escalation destination; and
• document who owns the incident after the final step.

A policy that ends with "notify everybody repeatedly" is usually a sign that the ownership model needs work.

Step 5: Add Severities Only When They Change Notification Behavior

Better Stack uses severities as reusable alerting presets. Current severity options can include:

• call;
• SMS;
• email;
• push notification; and
• critical alert.

One unusual but important current product rule is that you must have at least one escalation policy before creating severities. The current documentation places them under Escalation policies → Severities.

A practical workflow is therefore:

1. create a simple escalation policy first;
2. create a severity preset if your team needs reusable notification behavior;
3. return to the policy and apply the severity as appropriate.

Do not create "High", "Medium", and "Low" solely because those labels are common. Each severity should cause a meaningful difference in how responders are notified or how the incident is handled.

Personal alert settings still matter

Better Stack also documents personal alert settings under Settings → Alerts once the team has an escalation policy. Team-wide severity defaults and personal delivery settings should be reviewed together so that a supposedly urgent path does not depend on a channel a responder has disabled or never configured.

Step 6: Assign the Policy to a Monitor

This is the step most likely to be missed.

Creating an escalation policy does not apply it automatically.

Better Stack's current documentation says to open the relevant monitor, find its on-call/escalation settings, choose Escalation policy, select the policy, and save the monitor.

The backup-schedule guide gives a similar workflow:

1. Go to Monitors.
2. Select a monitor.
3. Select Configure.
4. Find Escalation policy.
5. Choose the policy.
6. Save changes.

For multiple monitors, Better Stack also documents a bulk action for configuring on-call escalation.

Verify resource assignment

Before testing notifications, create a simple mapping:

This is more useful than merely listing policies. A policy with no assigned resource cannot protect anything.

Step 7: Validate the Routing Safely

There are two different things to validate:

1. configuration validation — the policy contains the intended steps and is attached to the intended resource;
2. delivery validation — notifications actually reach the intended responders in the expected order.

Always do the first. Do the second in a controlled way.

Option A: Use a manual test incident with a test policy

Better Stack currently supports manual incidents from Uptime → Incidents → Report a new incident. An escalation policy can also have a policy-specific incident form whose escalation steps determine notification routing.

This gives you a useful testing method:

1. create or clone a policy that points only to test-safe recipients;
2. use the policy-specific manual incident form;
3. create an incident clearly named as a test;
4. observe the first notification;
5. acknowledge or allow the backup step to occur according to your test design;
6. resolve the incident; and
7. remove or archive the temporary test configuration.

Do not run an unannounced test against the production on-call rotation.

Option B: Use a non-production monitor

If you also need to validate the connection between monitoring and escalation, use a temporary monitor with a controlled endpoint. Assign the policy to a test resource and deliberately make that test endpoint fail.

Again, the goal is to test the routing path without breaking a production service.

This tutorial does not claim that PerfMonitoring executed notifications in your Better Stack account. The procedure is derived from the current product documentation and should be performed in your own controlled environment.

Verify the Setup

Before considering the escalation policy complete, confirm:

• the policy name identifies the protected service/team;
• step 1 points to the real primary owner;
• the delay reflects your response objective;
• step 2 points to a real backup owner;
• any repeat/fallback behavior is intentional;
• severities map to meaningful notification behavior;
• the policy is assigned to the intended monitor(s);
• responders' personal alert settings support the intended channels; and
• a controlled test follows the expected route.

The strongest validation is not "the policy exists." It is "the right resource triggers the right ownership path."

Common Problems and Fixes

Problem: The policy was created but incidents still use simple notifications

Cause: the policy was never assigned to the monitor.

Fix: open the monitor configuration, select Escalation policy, choose the intended policy, and save. Better Stack explicitly documents assignment as a separate step.

Problem: The backup responder never gets alerted

Cause: there may be no second step, the delay has not elapsed, the incident was acknowledged, or the second step targets the wrong schedule/team.

Fix: inspect the policy step order and the current on-call membership of the backup schedule. During a controlled test, confirm whether acknowledgement stops further escalation as expected.

Problem: Everybody is alerted too quickly

Cause: steps have no meaningful delay, the policy includes broad destinations immediately, or a high-severity preset uses several disruptive channels.

Fix: align the first step with accountable ownership and introduce escalation only after the chosen response window. Remove redundant destinations.

Problem: Notifications repeat excessively

Cause: repeat behavior is too aggressive or is being used instead of a real fallback owner.

Fix: review repeat count/delay and consider a backup or fallback policy. Repetition should not substitute for organizational responsibility.

Problem: A severity cannot be created

Cause: according to current Better Stack documentation, severities require at least one escalation policy.

Fix: create the initial policy first, then open Escalation policies → Severities and add the reusable notification preset.

Problem: A responder says they never received the configured channel

Cause: personal alert settings, phone/push setup, channel configuration, or team membership may not match the policy.

Fix: verify the team member's Settings → Alerts, on-call schedule membership, and integration/channel setup. Test with that person's knowledge rather than repeatedly triggering production alerts.

Problem: A policy exists but nobody knows which monitors use it

Cause: policy ownership is not documented.

Fix: review assigned resources in Better Stack and maintain a simple service-to-policy mapping. Current Better Stack documentation also provides policy resource views and bulk monitor assignment options.

Best Practices

Escalate ownership, not noise

The purpose of a policy is to ensure someone takes responsibility. Adding more channels and more recipients does not necessarily improve response.

Make the first step specific

A primary on-call schedule for the service is usually clearer than immediately notifying an entire engineering organization.

Keep delays connected to incident objectives

Choose escalation timing from the response commitment and severity. Revisit the delay after real incidents reveal whether it is too short or too long.

Separate severity from service ownership

Severity answers "how urgent is this and how should we notify?" Ownership answers "who is responsible?" Do not encode both concepts in vague policy names.

Maintain a final fallback

For important services, decide what happens if primary and backup responders do not acknowledge. That can be a broader team, manager, incident commander path, or another defined policy — but it should be deliberate.

Test changes before an outage tests them for you

When you modify responders, schedules, delays, severities, or integrations, run a controlled validation with consent from the affected people.

Include response instructions

Better Stack currently supports instructions/todo-list steps in escalation policies. If your team uses them, keep the first actions concise: dashboard, runbook, service owner, and immediate safety checks. Do not paste secrets or dangerous production commands into alert instructions.

When This Setup Makes Sense

A two-step escalation policy is a good default when:

• a service has a defined primary on-call responder;
• there is a real backup rotation or team;
• incidents require acknowledgement;
• missing an alert matters more than sending only an email; and
• the team wants predictable ownership without paging everybody immediately.

More advanced policy logic can make sense for organizations with:

• service ownership metadata;
• multiple regional schedules;
• business-hours versus after-hours routing;
• incident severity classes; or
• different fallback policies.

Add those capabilities only when the underlying organizational rules are already clear.

FAQ

What should happen if the first responder does not acknowledge?

The policy should escalate to a defined backup responder, schedule, team, or fallback path after a deliberate delay. The delay should reflect your incident-response objective rather than a copied default.

How many escalation steps should I create?

Use the minimum number required to reach accountable ownership. Primary plus backup is often enough for a first policy. Additional steps should correspond to real organizational roles, not just more people to notify.

How do severities affect Better Stack escalation policies?

Severities are reusable notification presets that can define channels such as calls, SMS, email, push, and critical alerts. Current Better Stack documentation requires at least one escalation policy before creating severities.

Does creating a Better Stack escalation policy apply it automatically?

No. Current Better Stack documentation explicitly requires assigning the policy to the monitor, heartbeat, or integration that should use it.

Can I test an escalation policy without taking my website down?

Yes. Better Stack supports manual incident creation, including policy-specific incident forms. Use a test policy or test-safe recipients so validation does not page an unsuspecting production rotation.

Conclusion

A useful escalation policy is an ownership model expressed in software. Start with a primary responder, a real backup, and a delay grounded in your response objective. Add severities, repeats, fallback policies, or routing rules only when they represent rules your team actually follows.

Finally, verify that the policy is attached to the right monitor and run a controlled test. A perfectly designed policy that is not assigned to a resource — or whose notifications cannot reach responders — provides no incident-response protection.

For the signal side of the workflow, see How to Set Up Uptime Monitoring with Better Stack.

References

1. Better Stack Documentation — "Escalation policies" — Better Stack — https://betterstack.com/docs/uptime/escalation-policies/ — accessed September 10, 2026.
2. Better Stack Documentation — "Create a backup on-call schedule" — Better Stack — https://betterstack.com/docs/uptime/creating-a-backup-oncall-schedule/ — accessed September 10, 2026.
3. Better Stack Documentation — "Severities" — Better Stack — https://betterstack.com/docs/uptime/severities/ — accessed September 10, 2026.
4. Better Stack Documentation — "Create incidents manually" — Better Stack — https://betterstack.com/docs/uptime/creating-incidents-manually/ — accessed September 10, 2026.
5. Better Stack Documentation — "Create escalation policy" — Better Stack Uptime API — https://betterstack.com/docs/uptime/api/create-escalation-policy/ — accessed September 10, 2026.