How to Set Up Uptime Monitoring with Better Stack

A website can be reachable from your laptop while still failing for external users because of DNS, TLS, routing, application, or regional problems. Better Stack's uptime monitoring checks a service from outside your infrastructure and can open an incident when the configured success condition stops being true.

This tutorial shows a conservative first setup for an HTTP(S) endpoint. The goal is not to enable every option. It is to create one monitor whose success condition you understand, connect it to a safe notification path, verify that checks are healthy, and know how to diagnose a false or real failure.

Last verified: September 10, 2026. Better Stack changes its UI and plan-dependent monitoring intervals over time, so recheck the linked official documentation if a label or available interval differs.

What You'll Accomplish

By the end, you will have:

1. an HTTP status monitor for a public website or health endpoint;
2. a clear definition of what counts as success;
3. a basic alert or escalation path;
4. evidence that Better Stack is checking the endpoint successfully;
5. a safe method for validating incident behavior without taking production offline; and
6. a troubleshooting checklist for redirects, timeouts, WAF blocks, and unexpected status codes.

Prerequisites

You need:

• a Better Stack account and workspace;
• permission to create monitors and configure on-call/escalation behavior;
• a publicly reachable HTTP or HTTPS URL;
• a notification destination you can use for validation without paging an entire production rotation; and
• permission to create a temporary test monitor if you want to validate failure behavior.

For a first monitor, prefer an endpoint with simple and stable semantics. A dedicated /health or /ready endpoint can be better than a complex home page if it reflects the user-facing dependency you actually care about. Do not use an internal endpoint that Better Stack cannot reach from the public Internet unless you have a deliberately designed private-monitoring path.

Quick Answer

In Better Stack, open Monitors → Create monitor, enter the URL, and create an HTTP status-code monitor. The default status monitor treats HTTP 2xx responses as success. Configure a check frequency appropriate for the service and your plan, then choose either the simple primary-responder notification path or an escalation policy. After saving, wait for several successful checks and confirm the monitor reaches an Up state. To test incident behavior, use a temporary monitor or controlled test endpoint rather than breaking the production URL. If checks fail unexpectedly, inspect the returned status, redirect behavior, timeout, TLS/DNS path, and whether a WAF or access-control rule is blocking Better Stack probes.

Step 1: Choose a Success Condition That Matches the Service

Better Stack's standard HTTP status monitor checks whether the URL returns an HTTP 2xx response. A non-2xx result can cause an incident for that monitor.

That makes the default monitor appropriate when the statement you want to test is simply:

"This endpoint should be reachable and should return a successful HTTP response."

Do not make the monitor more complicated without a reason. For example:

• If /health returning 200 is sufficient, a normal status-code monitor is easier to reason about than a keyword monitor.
• If your application intentionally returns a specific non-2xx code in a healthy state, use the expected-status-code behavior rather than pretending every healthy service must return 200.
• If a 200 response can contain a known failure page, consider a keyword monitor or another deeper check.
• If you need to test an authenticated API request with a body or custom method, use the request options under the monitor's advanced settings.

The important design decision is the contract between the service and the monitor. A monitor should fail when a user-relevant dependency is broken, not merely because an incidental implementation detail changed.

Step 2: Create the HTTP(S) Monitor

In the current Better Stack documentation, the basic workflow is:

1. Open Monitors.
2. Select Create monitor.
3. Enter the URL or IP address in the URL field.
4. Keep the monitor based on HTTP availability/status if that is your intended check.
5. Configure the on-call/notification option.
6. Select Create monitor.

Use a descriptive name if the interface offers one. Prefer something that identifies both the service and the purpose, such as:

Customer portal - public HTTPS health

A name like Website 1 becomes hard to interpret during an incident, especially after the account contains dozens of monitors.

Use the URL users actually depend on

Monitoring only an origin hostname can miss failures introduced by a CDN, DNS provider, TLS termination layer, or reverse proxy. Conversely, monitoring only the marketing homepage might not prove that a critical API is healthy.

Choose the URL based on the failure you want the monitor to detect. It is reasonable to have multiple monitors later, but the first monitor should have one understandable responsibility.

Step 3: Set Frequency and Timeout Conservatively

Last verified September 10, 2026: Better Stack's current check-frequency documentation says available frequencies range from 3 minutes on free plans to 30 seconds on paid plans. These are plan-dependent product settings, not timeless technical constants.

A shorter interval detects failures sooner, but it does not automatically make the monitor more useful. Consider:

• the response objective for the service;
• whether the endpoint is inexpensive to request;
• the alert confirmation behavior;
• the chance of transient network failures; and
• how quickly a human can realistically act.

The monitor API also exposes a request timeout, and the current API documentation states that the check frequency must be at least as long as the timeout. The UI may present only supported values.

For a normal web endpoint, choose a timeout that distinguishes a genuinely unusable response from ordinary latency. Do not set an extremely low timeout solely to make a dashboard look strict. If normal traffic occasionally takes several seconds because of a legitimate workload, a two-second monitoring timeout may generate noise rather than useful incidents.

Consider confirmation and recovery behavior

Better Stack's monitor settings also include confirmation and recovery concepts. A confirmation period delays opening an incident after a failure is observed; a recovery period determines how long a monitor must remain healthy before an incident is automatically resolved.

These settings can reduce flapping, but larger delays also slow detection and recovery reporting. Tune them from the service's actual behavior and incident history instead of copying values from another system.

Step 4: Decide How Redirects and Status Codes Should Behave

Redirect behavior matters because many sites redirect:

• HTTP to HTTPS;
• a bare domain to www or the reverse;
• old paths to canonical paths; or
• unauthenticated requests to a login page.

Better Stack's monitor API includes a follow_redirects option. Whether you should enable it depends on the statement you want to test.

For a public homepage, following a deliberate HTTP-to-HTTPS redirect may be appropriate. For an API health endpoint, an unexpected redirect to a login page may be exactly the failure you need to catch.

Likewise, the standard status monitor checks for 2xx. Better Stack also supports an expected-status-code monitor when you need to define particular acceptable codes.

Document the expected behavior in the monitor name, description, or runbook. When an incident occurs at 03:00, responders should not have to reverse-engineer why a 302 is considered healthy or unhealthy.

Step 5: Add Headers or Authentication Only When Necessary

Current Better Stack documentation places request customization under:

Monitors → select a monitor → Configure → Advanced settings → Request parameters

The monitor can use request headers and HTTP authentication, and the API exposes request methods and request bodies for applicable monitor types.

Treat monitor credentials as production credentials:

• use a dedicated monitoring token where possible;
• give it only the permission required for the health request;
• never paste a real bearer token into documentation, screenshots, tickets, or source control;
• rotate it through your normal secret-management process; and
• make the monitored request read-only and non-destructive.

A public health endpoint is simpler than an authenticated one, but it must not reveal sensitive internals. Do not expose database credentials, stack traces, deployment secrets, or detailed infrastructure topology in the health response simply to make monitoring easier.

Step 6: Connect a Safe Alerting Path

Better Stack's getting-started workflow currently provides a simple Notify the primary responder path, while escalation policies support more advanced routing.

For a first monitor, simple routing is often preferable. Choose a test-safe notification method and verify the relevant user or on-call configuration before enabling disruptive channels such as phone calls or critical alerts.

If your team already has a formal on-call process, attach an escalation policy instead. Creating a policy does not automatically apply it to a monitor; the policy must be selected in the monitor's escalation settings.

A useful separation is:

• monitor configuration decides whether the service is healthy;
• escalation configuration decides who should respond.

Do not compensate for a noisy monitor by adding a complicated escalation tree. Fix the monitor signal first.

Step 7: Verify the Monitor Is Actually Healthy

After creation, do not stop at "the monitor exists."

Allow Better Stack to run several checks, then confirm:

1. the monitor status reaches Up rather than remaining Pending;
2. last_checked_at or the equivalent UI history is current;
3. recent checks correspond to the intended URL;
4. response times are plausible for an external request; and
5. there are no unexplained incidents.

Better Stack's API documents monitor states including pending, up, validating, down, paused, and maintenance. The UI may present these states in a friendlier form, but the important point is that a newly created monitor may wait for its first check before it becomes healthy.

If your endpoint is behind a CDN or has region-specific behavior, review the regional evidence available in Better Stack rather than relying on a single browser request from your own network.

Verify the Setup

A setup is complete only when you can answer yes to all of these:

• Is the intended URL being checked?
• Is the monitor using the intended success condition?
• Have several recent checks succeeded?
• Is the status currently Up?
• Is alert routing assigned to the intended person/policy?
• Could a responder understand what this monitor protects from its name and context?
• Have you validated failure behavior safely?

Safely validate failure behavior

Do not take your production website offline to prove monitoring works.

A safer pattern is to clone or create a temporary monitor that points to a controlled endpoint designed to fail, or to a temporary test resource whose status you can change without affecting users. Route that test monitor to yourself or a non-production test policy.

Observe whether an incident is created and whether the intended test notification arrives. Then remove or pause the temporary monitor.

This is a recommended validation pattern, not a claim that PerfMonitoring executed a live Better Stack incident in your account.

Common Problems and Fixes

Problem: Better Stack reports non-2xx while the browser appears fine

Likely cause: the browser follows a redirect, supplies cookies, or executes application logic that the monitor does not.

Fix: inspect the actual HTTP response chain without browser state. Confirm whether redirects should be followed and whether the final response matches the monitor's intended success contract.

Problem: The monitor is down because of a redirect

Likely cause: redirect following is disabled, or the redirect itself is unexpected.

Fix: determine whether the redirect is legitimate. For an intended public-site redirect, configure the monitor accordingly. For an API or health endpoint, fix the redirect if it indicates authentication or routing failure.

Problem: Requests time out even though the site usually loads

Likely cause: the request timeout is lower than real response behavior, or the endpoint intermittently stalls.

Fix: compare Better Stack response-time history with application/server telemetry. Increase the monitoring timeout only if the slower response is still acceptable to users; otherwise treat the timeout as a real performance symptom.

Problem: A WAF or access rule blocks monitoring probes

Likely cause: a firewall, bot-protection rule, authentication layer, or rate limiter treats synthetic probes differently from browsers.

Fix: confirm the block in WAF/server logs. Use Better Stack's current network/probe information when creating an allow rule, and make the rule as narrow as practical. Do not disable security controls globally just to make the monitor green.

Problem: A monitor stays Pending

Likely cause: the first check has not completed, the monitor is paused, or there is a configuration/connectivity issue.

Fix: wait for the configured check cycle, confirm the monitor is active, then inspect check/incident history. If the URL is unreachable from the public Internet, fix reachability or choose an appropriate monitoring architecture.

Problem: Notifications go to the wrong people

Likely cause: the monitor is using the simple primary-responder path or a different escalation policy than expected.

Fix: open the monitor's configuration and inspect the on-call/escalation setting. If an escalation policy is selected, verify the policy and its current responders separately.

Best Practices

Monitor user-visible outcomes

A green server does not guarantee a usable application. Prefer checks that represent a meaningful service boundary: public HTTPS, a readiness endpoint, or a critical API.

Give each monitor one clear responsibility

A monitor with many unrelated assertions becomes harder to diagnose. Split materially different failure modes when different teams or runbooks own them.

Use dedicated monitoring credentials

If authentication is required, use a dedicated, least-privilege credential. A user's personal account or full-access API token is a poor monitoring dependency.

Keep test alerts away from production on-call

Validate new monitors and escalation changes with a safe contact or test policy first. This protects responders from avoidable alert fatigue.

Tune from evidence

If a check repeatedly flaps because the endpoint normally responds near the timeout, either improve the endpoint or choose settings that reflect the actual service objective. Do not silently add long confirmation delays to hide instability.

Preserve external independence

Where possible, keep the monitor independent from the same failure domain it observes. An external availability check is useful partly because it can still run when your application stack is broken.

When This Setup Makes Sense

A basic Better Stack HTTP status monitor is a good fit when you need an independent answer to:

"Can an external client reach this endpoint and receive an acceptable HTTP response?"

Use a different or deeper check when that question is insufficient. Examples include:

• keyword monitoring when the response body must contain a known signal;
• API/request monitoring when method, headers, authentication, or body matter;
• heartbeat monitoring for scheduled/background jobs; or
• browser/synthetic transaction monitoring when a multi-step user journey must work.

The simplest monitor that correctly represents the risk is usually easier to maintain than an over-engineered check.

FAQ

What should a Better Stack uptime monitor check?

It should check an endpoint whose failure represents a meaningful service problem. For a basic website monitor, that is commonly a public HTTPS URL or health endpoint expected to return an HTTP 2xx response.

How do I avoid false downtime alerts in Better Stack?

Start by checking the correct endpoint and success code. Then inspect redirect behavior, timeout, check frequency, confirmation/recovery behavior, regional failures, and WAF rules. Do not solve false alerts only by delaying notifications.

Why can Better Stack fail while the site works in my browser?

Your browser may follow redirects, send cookies, use cached DNS, come from a different region, or be allowed by security rules that block synthetic probes. Compare the monitor's raw failure with server, WAF, DNS, and TLS evidence.

Should I use the shortest available check frequency?

Not automatically. Choose a frequency that matches your detection objective, endpoint cost, plan, and response process. Faster checks are useful only if the signal remains reliable and the team can act on it.

Conclusion

A reliable Better Stack setup starts with a clear definition of success, not with the largest number of enabled options. Create one understandable HTTP monitor, tune its frequency and request behavior to the service, route alerts safely, and verify both healthy checks and controlled failure behavior.

Once the signal itself is trustworthy, the next step is to build a deliberate on-call escalation path. See the sibling tutorial, How to Configure Better Stack Escalation Policies for On-Call Alerts, for a primary-to-backup routing model.

References

1. Better Stack Documentation — "Get started with monitoring" — Better Stack — https://betterstack.com/docs/uptime/monitoring-start/ — accessed September 10, 2026.
2. Better Stack Documentation — "Uptime monitor" — Better Stack — https://betterstack.com/docs/uptime/uptime-monitor/ — accessed September 10, 2026.
3. Better Stack Documentation — "Check frequency" — Better Stack — https://betterstack.com/docs/uptime/check-frequency/ — accessed September 10, 2026.
4. Better Stack Documentation — "Request parameters, headers and HTTP authentication" — Better Stack — https://betterstack.com/docs/uptime/request-parameters-headers-and-http-authentication/ — accessed September 10, 2026.
5. Better Stack Documentation — "Create monitor" — Better Stack Uptime API — https://betterstack.com/docs/uptime/api/create-a-new-monitor/ — accessed September 10, 2026.
6. Better Stack Documentation — "Response attributes" — Better Stack Uptime API — https://betterstack.com/docs/uptime/api/monitors-api-response-params/ — accessed September 10, 2026.