Downtime Monitoring: Downtime Monitor for Website Downtime Monitoring Every 60 Seconds

Every downtime monitor answers one question on each check: did this endpoint respond the way it should, within the time allowed? The useful part is in the detail of that sentence, because each part of it maps to a failure you have probably already had.

Did it respond. A connection that is refused or never completes means the server, the load balancer or the network in front of it is gone. A DNS lookup that fails means nobody can find the site at all, which is what an expired domain or a bad nameserver change looks like from the outside.

The way it should. A response is not the same as a working page. WordPress returns a 500 with its critical error screen when a plugin update breaks, a database outage produces an error page with a 500 or 503, and a host that has suspended an account often answers with a redirect to a holding page. Comparing the status code against the one you expect is what separates a live site from a site that is merely answering.

Within the time allowed. A request that takes 45 seconds has technically succeeded and has practically failed. Setting a timeout per endpoint lets you decide where slow becomes down for each page, instead of accepting a single global number.

Tools that only ping a server, or only check that port 443 is open, miss the second and third cases entirely. That gap is why a site can show 100 percent uptime in one tool while the checkout has been returning errors all afternoon. If you want the record of those incidents kept for later, the website downtime tracker page covers what gets stored and for how long.

People searching for real time downtime monitoring usually want the alert the instant a site fails. In practice the fastest honest answer is about a minute or two, and anything that claims to be faster is either checking far more often than most sites need or alerting on single failed requests.

Here is why. A single timed out request on the public internet is often not an outage. A packet gets lost, a resolver stalls, a CDN edge restarts. If the monitor opens an incident on that one request, it phones you at 3am for something that fixed itself in four seconds. Do that twice and you turn the phone alerts off, which defeats the whole purchase.

TrackDowntime handles it by failure type. A wrong status code is unambiguous, so it opens the incident on that check. A timeout is ambiguous, so it is rechecked twice, five seconds apart, and only becomes an incident if both rechecks fail too. DNS timeouts get three rechecks ten seconds apart. On a 60 second interval that means a genuine outage is confirmed and alerted within roughly two minutes in the usual case, and the alerts you get are ones you still believe six months later.

Interval matters more than any of that. On 5 minute checks, a failure can run close to five minutes before the monitor even looks. Starter runs 5 minute checks, which is fine for a brochure site; Professional and Enterprise run every 60 seconds, which is what anything transactional needs.

For a lot of US businesses the thing that actually goes down is not the marketing site. It is the API the mobile app calls, the endpoint the point of sale system posts orders to, or the webhook receiver a payment provider depends on. Those rarely have a page a human would notice is broken.

Application downtime monitoring works the same way as website monitoring, with three settings that make it accurate. First, send the headers the route needs: an API key or an authorization token goes out with every check on Professional and Enterprise, so you test the authenticated path. Second, set the expected status to whatever the route should return, which might be 200, 204 or even 401 for a route you are deliberately checking stays protected. Third, turn redirect following off on routes that should never redirect, so a misconfigured proxy that starts sending API clients to a login page opens an incident instead of passing silently.

Add each critical route as its own endpoint. An API is rarely all up or all down; the orders route can fail while the product catalog is fine, and a single base URL check will report healthy through that. On Enterprise the endpoint count is unlimited, which is the plan that fits teams monitoring dozens of routes across several services.

Detection is only half the job. The other half is getting a human to the problem while it is still small, and that is where most monitoring setups quietly fail, because the alert goes to an inbox nobody reads after 6pm.

When an incident opens, TrackDowntime emails the account owner and, on Professional and Enterprise, sends an SMS and places an automated phone call to the numbers on the endpoint. The alert then repeats on a fixed schedule while the endpoint is still failing: at 5, 10, 15, 20, 30, 40, 50 and 60 minutes, then at 2, 4, 8, 24, 48 and 96 hours. A call that goes to voicemail at 2am is followed by another one, not by silence. When a check succeeds again the incident closes with its measured duration and a recovery email goes out.

None of those alerts are metered. Tools that sell SMS and voice as credits tend to produce either a surprise invoice after a bad night or, worse, stop alerting once the balance runs out halfway through an outage. The downtime alerts by phone call page goes deeper on escalation and what the call says.