---
title: I get alerts but my site is up
description: Find out why a monitor reports a problem when the site opens fine in your browser, and stop the false alarms.
section:
title: Fix a problem
order: 3
order: 1
lastUpdated: 2026-10-31
next: ["/docs/guides/add-a-monitor", "/docs/concepts/http-monitors"]
keywords:
["false positive", "false alarm", "flapping", "site is up", "wrong alert", "degraded", "timeout"]
---
Start with the alert itself: open Alerts, click View History, and check the **Event** column. A Degraded event means the site answered, but slowly. A Down event means the check got no answer, the wrong status code, or the wrong content.
## If the alert says Degraded
A response that takes 5 seconds or longer counts as degraded, and a degraded check alerts just like a down one. Your browser may load the page quickly from its cache while a fresh request from the monitor's region takes longer.
To fix it, point the monitor at a lighter URL, such as a health-check route, with Edit Monitor. To accept slower responses, raise the monitor's `degradedAfterMs` (up to 30,000) through the [HTTP Monitors API](/docs/api/resources/http-monitors#update-monitor).
## If your server doesn't answer HEAD requests
Monitors send `HEAD` requests, which ask for the headers without the page. Some servers and frameworks answer `HEAD` with `404` or `405` even though the page opens fine.
A Slack, Discord or webhook alert names the status it received, as in `Response status: 405 (expected 200)`, and the alert email lists it too. To switch to `GET`, add a content check under **Content Monitoring** on Edit Monitor (a check needs the body, so it always sends `GET`), or set `"method": "GET"` through the API.
## If the expected status code is wrong
The monitor is down whenever the final status code differs from Expected Status Code. Redirects are followed first, so a URL that redirects to a login page is compared on the login page's code.
Open Edit Monitor and set Expected Status Code to what the URL returns when it is healthy, or use the URL it finally lands on.
## If the region can't reach your site
Each monitor checks from the one Region you picked, and a single failed check alerts. No answer within 10 seconds counts as down. A site that blocks or rate-limits traffic from some countries, or a network problem between that region and your host, produces alerts your own browser never sees.
Pick the region closest to your visitors in Edit Monitor. If your firewall or bot protection blocks automated traffic, allow Uptime's checks by their Web Bot Auth signature; see [Recognizing Uptime's Checks](/docs/concepts/http-monitors#recognizing-uptimes-checks).
## If a content check no longer matches
A failed content check makes the monitor down even with a `200` status. Text changed by a redesign, a translation or a cookie banner is the usual cause, and Contains checks are case sensitive when Case sensitive matching is ticked.
Open Edit Monitor and update or Delete the check under **Content Monitoring**.
## If the alert came from the SSL certificate
With Enable SSL Monitoring on, the monitor alerts as the certificate's expiry approaches, even while the site is up. The date comes from Certificate Transparency logs, which list the newest certificate issued for the host; if your server still serves an older one, the dates differ.
Check the **SSL Certificate** card on the monitor's page. To use your certificate's real date, enter it in Certificate Expiry Date on Edit Monitor.
No. The first failing check sends the alert, so you hear about an outage as early as possible. Repeats while the monitor stays broken follow the alert's cooldown.