Why Astrina Uptime Alerts Fire When the Site Is Still Online

Can an uptime alert be “true” even when the homepage loads?

Yes. A browser tab showing your homepage does not prove that the monitored endpoint passed Astrina’s check, and that difference is the first thing to understand when you ask why Astrina uptime alerts fire when the site is still online. A person may open the marketing page, see a logo, and assume everything is fine. Astrina may be checking /status, /login, or a JSON response instead of the front page.

That split matters. A homepage can load from cache while the actual endpoint times out on the server. A site can also return a 200 for the page shell and still fail the content rule because one required string is missing. Small detail, large consequence.

Think of it as two separate questions. One is “can I see something?” The other is “did the exact check pass?” Those are not the same.

Here is a simple example with 3 moving parts: the user loads https://example.com, the monitor checks https://example.com/api/health, and the API returns a 500 for 90 seconds. Visitors may never notice if the page is cached, but Astrina is right to fire because the tested endpoint is broken. That is not a contradiction; it is the point of monitoring.

Which part of the check is actually failing?

The fastest way to read an uptime alert is to isolate the failed layer. DNS, TCP, TLS, HTTP, redirects, and body checks fail for different reasons, and each one leaves a different trace. If you skip that step, you will waste time blaming “the site” when only one layer slipped.

DNS failure means the probe could not find the host. TCP failure means the host was found but the connection could not open. TLS or SSL failure means the certificate, hostname, or handshake did not satisfy the probe. HTTP failure means the server answered, but with the wrong status code. Redirect failure means the chain went somewhere unexpected or exceeded a limit. Content-match failure means the page loaded, but the body did not include the expected text.

Those categories are concrete, not cosmetic. A 301 redirect to a login page may still look “online” to a human, yet the monitor can fail if it expects a 200 from the original path. A certificate expiring in 2 days may let some browsers warn and some not, while Astrina can already flag the TLS state. That is the kind of difference that turns into a confusing alert at 09:17.

If your check is aimed at a private endpoint, the failure can be even narrower. One endpoint can return 200 while another returns 403 because of an auth rule added last week. The site is up, but the path is not.

Why do users and monitors see different results at the same time?

Users and monitors do not see the web from the same place. A browser may benefit from local cache, an active session, or a fast CDN node near the visitor. Astrina’s probe may hit a different region, a different IP path, or a cold request with no browser state at all.

That difference explains a lot. One visitor in London loads the site in 1 second. Another probe in a different location sees a timeout at 5 seconds because a transit path is congested. Both reports can be true at once.

CDN behavior is a common cause. If the edge serves the homepage but not a nested asset, the page may still appear “fine” to the naked eye. A cached shell can hide a broken origin. The monitor, however, may be checking the origin path directly or a route that the CDN does not cache for long.

Geo differences can matter too. A firewall may allow traffic from your office IP and block a probe IP range. A routing issue may affect one continent for 12 minutes and leave the rest untouched. That kind of split view is annoying, but it is real. No amount of hand-waving changes the packet path.

Sometimes the result is even simpler: a browser retries automatically, while a monitor does not. A page that eventually loads after 3 failed attempts can still trigger an alert if the check times out on the first pass. That does not mean Astrina is “too strict.” It means the service is flirting with failure.

Could a partial outage trigger an alert even if the main site works?

Yes, and this is one of the most common patterns. The public site can stay reachable while a dependency breaks behind the scenes. A checkout API, an image service, or a search backend can fail without taking the homepage down.

Consider an e-commerce site with 4 layers: the homepage, the product API, the payment gateway, and the inventory service. If the homepage is cached but the product API returns empty results, a visitor may still land on the page and see a banner. Astrina might check the API endpoint and fire immediately. The site is “up” in the casual sense, but a key function is down.

A single broken asset can also matter. If your monitor verifies that the hero image or a JavaScript bundle is present, a missing file can fail the content check even though the HTML loads. One missing file can be enough. That is not dramatic; it is operational reality.

Region-specific failures create a similar problem. Suppose one data center serves users in one country, while another region is degraded. The main site can load from the healthy region, yet requests from the broken region time out or return errors. The alert is not wrong. It is telling you that availability is uneven.

There is a more subtle case too: one slow dependency can push the response beyond the check’s limit. A page may eventually render after 8 seconds, but if the monitor threshold is 5 seconds, Astrina will fire. That is useful. Slow is often the first step before down.

What response details should you inspect first?

Start with the fields that tell you what failed, not what you hope failed. The first items to inspect are status code, response time, body match, certificate state, and redirect chain. If the alert includes a probe location, read that too, because location can explain a path-specific problem.

Read those fields in order. A 500 is a different problem from a 200 with the wrong body. A timeout is different again. If you see a redirect chain of 4 hops, ask whether the monitor should be following all 4 or should be watching a simpler endpoint. More hops, more places to fail.

Probe location deserves a second look. A result from Frankfurt can differ from a result from Singapore if a CDN node or upstream route is unstable. That detail often explains why one operator sees an outage while another sees nothing. Both operators are telling the truth from their side.

If your alert includes headers, keep an eye on cache-related ones. A response served from cache can hide origin failure for a while. A response marked “stale” or “miss” can reveal the real condition. Small clues matter.

When is this likely a false positive versus a real availability issue?

A false positive is usually narrow and repeatable in one small way. A real availability issue usually affects more than one check or becomes easier to reproduce. That distinction saves time. It also stops you from “fixing” the monitor when the service is the problem.

Look for a flaky dependency first. If the alert appears once, clears, and never returns during the next 30 minutes, a transient upstream issue is possible. If it fires every 2 minutes on the same endpoint, the check may be too strict or the service may truly be unstable. Patterns matter more than stories.

A too-strict check often looks like this: the page renders, but a content assertion expects an exact phrase that changed in last week’s release. The product team swapped “Sign in” for “Log in,” and the monitor began failing on a body mismatch. The site is online. The check is stale.

By contrast, a genuine issue often shows signs in more than one place. The homepage loads slowly, the API returns 503, and the certificate is close to expiry. That is not a single oddity. That is a stack of small warnings pointing in the same direction.

There is also the “depends who you ask” case. Users behind a corporate VPN may hit a stable path, while the probe hits a broken one. That can look like a false positive at first, but it is usually a real reachability problem for at least one audience. A site that is up for 80% of visitors is not fully up.

What should you change if the site is “up” but Astrina keeps firing?

Make the monitored target match the thing you actually care about. If the homepage is fine but the API matters, monitor the API. If the homepage is too noisy, move the check to a cleaner health endpoint. That one change can remove a lot of noise.

Next, tighten or relax the content rule only when the rule is the problem. A check for a specific phrase is useful if the phrase is stable. It is less useful if the text changes with every release or localization. If you do keep a body check, choose a string that is unlikely to shift on a minor content update.

You should also review the redirect path. A 302 to a login wall may be acceptable for users but not for a monitor. In that case, monitor the endpoint that represents service health instead of the public route. That is a configuration choice, not a philosophical one.

If timing is the issue, set the monitored path to something lighter. A full homepage with 12 assets is a poor health signal if all you need is one quick response. A lighter endpoint gives a better answer and fewer false alarms. Fast checks age better than fancy ones.

If you are still setting up the monitor, the agent setup path is here: * and the normalized visible-text size. If you also need to track related configuration in analytics, see how to add astrina to google. And if you manage multiple properties, the article on astrina for agency clients with multiple sites is a useful next step.

One last check: compare what the alert says with the exact URL, not the brand name. If the alert is firing on /api/health and the homepage is up, that is expected behavior. If the alert is firing on the homepage itself, then the problem deserves a deeper look, because a homepage that serves but fails content, TLS, or routing checks is still a real incident for Astrina.