Skip to main content
Back to Features
Uptime monitoring

Uptime monitoring that catches downtime before customers do

Checked from multiple global locations. Network-related failures go through up to 4 check attempts with exponential backoff before an incident opens; other failures, like a status-code or keyword mismatch, open an incident on the first failed check. On paid plans, verification checks from other locations also run before network-related incidents open. Choose a check interval from 30 seconds to 24 hours, depending on your plan.

Multi-location checks
Set up in under 60 seconds
Free plan, no credit card
4 monitors · checks from multiple global locations
MonitorStatusUptime 30dResponseChecked
shop.acme.ioDown98.71%timeoutnow
app.acme.ioUp99.98%142ms30s
blog.acme.devUp100%88ms1m
api.acme.comUp99.95%210ms30s
1 monitor down · shop.acme.io failed after 4 attempts
Uptime monitoring is included in the free plan.Compare all plans

A rolling SLA you can actually report

WebPixie tracks uptime over time and rolls it into an SLA figure, with the incident count and response trend behind it, so you have a number to share instead of a guess.

30-day uptime

99.98%

Incidents

2

MTTR

4m

Avg response

138ms

Full uptimePartial downtimeOutage

The SLA is calculated on an industry-standard basis that excludes periods when monitoring was paused, so the figure reflects real availability.

Checked from multiple global locations

Checks can run from multiple global locations, and paid plans use other locations to verify network-related failures before opening an incident.

Monitorapp.acme.io
London142msUp
Istanbul168msUp
New York121msUp

Each check validates more than a 200

Set the HTTP method, headers, expected status code, a body keyword, and authentication, so a check confirms the page is actually working, not just reachable.

MethodGET
Expected status200
Request headersAuthorization, X-Api-Key
Keyword match"Welcome back"
AuthenticationBasic
Interval1 min

Up to four attempts, then a second opinion

A network failure must survive up to four check attempts with exponential backoff before an incident is considered. On paid plans, WebPixie also verifies from other locations before opening one.

Check failstimeout
Retry 1
Retry 2
Retry 3
Verifyother location
Incident opens
Accelerated re-checksfaster recovery

Applies to network failures such as timeouts and connection errors. Status code or keyword mismatches open an incident on the first attempt. Cross-location verification is available on Starter and above; if verification passes, no incident opens. Once an incident opens, accelerated re-checks run on every plan to detect recovery sooner.

How WebPixie watches your uptime

WebPixie runs uptime checks from multiple global locations on a schedule and alerts you when a check confirms a failure. There is no agent to install, no DNS changes, and no server access needed. Every check verifies the HTTP response code, response time, HTTPS connectivity, and any custom keyword you configure. Over time you get uptime statistics, SLA reports that exclude unmonitored periods, and 30-day trends, so you can measure reliability and track mean time to recovery. While an incident is open, WebPixie re-checks the monitor more often than its normal interval to catch recovery sooner and time the outage.

Network-related failures, like timeouts or connection errors, go through up to 4 check attempts with exponential backoff. On paid plans, if all attempts fail, WebPixie also runs verification checks from other locations before opening an incident, so a momentary flicker on one route does not wake you at 3am. When a failure is confirmed, alerts route through email, Slack, or webhook depending on your plan.

Checks can run from multiple global locations, including London, Istanbul, and New York. This gives you visibility from more than one network path when reachability problems are regional.

01

Stop refreshing the homepage to check if it is working

Automated checks tell you what manual refreshing cannot

Most downtime starts predictably: a deploy goes wrong, a memory leak builds, a DNS record changes. WebPixie lets you set a check interval from 30 seconds to 24 hours depending on your plan, so high-priority monitors run often and low-priority ones run sparingly. When a check fails, an alert routes to your preferred channel.

02

Receive smart alerts, not 3am false alarms

Up to four check attempts, then cross-location verification on paid plans

Network-related failures, like timeouts or connection errors, go through up to 4 check attempts with exponential backoff. On paid plans, if all attempts fail, WebPixie also verifies from other locations before opening an incident, so a momentary flicker does not wake you. Alerts route through email on every plan, Slack on Starter and above, and webhooks on Pro and above.

03

Check from multiple global locations

A regional outage hits one path, not the others

A site can look fine from one location while being unreachable from another. WebPixie checks from multiple global locations, such as London, Istanbul, and New York, so regional reachability problems are easier to review.

04

What uptime monitoring checks, and what it does not

HTTP availability vs the rest of the WebPixie suite

Uptime monitoring checks HTTP and HTTPS reachability using the HTTP method, headers, expected status code, and authentication you configure, plus response times and a body keyword that confirms the page is functioning correctly, not just returning a 200. An expired SSL certificate or lapsed domain will make the HTTPS check fail, so uptime sees the symptom once the site is already down. What it cannot do is warn you ahead of expiry, or surface a changed DNS record or a broken link on a deeper page as a cause-level finding.

Set up uptime monitoring in 60 seconds

Free plan, no credit card. 5 monitors with no time limit.

Everything you need to monitor a website. In one workspace.

A quick look at other WebPixie features.

Why teams choose WebPixie for uptime

Up to four attempts, then verified from another location

Up to four check attempts with exponential backoff filter out transient network noise. On paid plans, WebPixie also verifies from other locations before opening an incident.

Multiple locations, independent network paths

Checks can run from multiple independent locations, such as London, Istanbul, and New York, so regional reachability problems are easier to separate from one-path network noise.

Check intervals from 30 seconds to 24 hours

Pick the interval each monitor needs, from 30 seconds to 24 hours, with the fastest intervals available on higher plans.

Frequently Asked Questions

Common questions about uptime monitoring.

Website monitoring is the practice of automatically checking whether a website is reachable, responding well, and returning expected results. Monitoring services like WebPixie check your site from multiple global locations, verify HTTP response codes, check SSL certificate validity, watch for DNS record changes, and crawl your pages in depth. When something goes wrong, the service sends alerts through your chosen channel so you can respond without waiting for a user report.

There are several types of website monitoring, each catching a different class of issue:

Most teams need all of them. That's exactly why WebPixie brings them together on a single platform.

WebPixie sends alerts after a scheduled check confirms an issue. The exact time-to-alert depends on your monitor's check interval, which can range from 30 seconds to 24 hours depending on your plan.

To reduce false-positive noise, network-related failures such as timeouts or connection errors go through up to 4 check attempts with exponential backoff. On paid plans, if all attempts fail, WebPixie also runs verification checks from other locations before opening an incident. This helps confirm a real outage versus a flaky network, so you don't get woken at 3am for a routing flicker in one region.

Email alerts fire on every plan, including Free. What Free doesn't get is Incident Management: an incident list, lifecycle tracking, incident reporting, and the ability to add a note - those start on Starter, alongside Slack (Starter and above) and webhooks (Pro and above). Webhooks integrate with PagerDuty, Opsgenie, or any incident management tool you already use. For SMS or voice workflows, route the webhook through a receiving service that provides them.

Monitoring intervals are plan-based, with current minimums set as: Free (15 minutes), Starter (5 minutes), Pro (1 minute), Enterprise (30 seconds). You can also configure longer intervals up to 24 hours for lower-priority monitors, so a critical API health endpoint can run more often than a low-risk marketing page. In uptime monitoring, the interval affects how quickly WebPixie can detect a failure before the down-detection logic confirms the issue and opens an incident. Faster intervals are useful for customer-facing applications, checkout flows, authentication services, and status endpoints where even short downtime matters. Slower intervals may be enough for informational pages or non-critical internal tools. Check intervals, uptime check limits, and monitoring locations vary by tier, so compare the details on the pricing page. Confirmed failures can then flow into incident management and your configured notification channels.

WebPixie marks a site as down when an uptime check fails the response rules configured for that monitor. A failure can come from a timeout, connection error, unexpected HTTP status code, missing body keyword, or another expected condition that does not match. Uptime monitoring supports custom HTTP methods, headers, expected status codes, authentication, and keyword validation, so “down” can mean more than a simple 500 error. For network-related failures such as timeouts or connection errors, WebPixie makes up to 4 check attempts with exponential backoff before confirming the failure. On paid plans, if all attempts still fail, WebPixie also runs verification checks from other locations before opening an incident, which reduces false positives further. Failures from deterministic conditions, such as an unexpected status code or a missing keyword, open an incident on the first failed check without retry. If the issue is confirmed, WebPixie creates or updates an incident and sends notifications through the channels available on your plan. Check intervals and location availability are plan-based, and you can compare them on the pricing page.

WebPixie can run uptime checks from multiple monitoring locations, including London, Istanbul, and New York. These locations help verify whether your website is reachable from more than one network path, which is useful when a problem affects only a specific region, provider, or route. Each uptime monitoring check can validate response status, response time, expected content, and other configured conditions before an incident is created. If no region is selected, WebPixie assigns one automatically. Multi-location checks and cross-location verification (available on paid plans) are especially useful for customer-facing sites, agencies managing client domains, and teams that need clearer evidence before escalating an outage. Compare plan coverage on the pricing page.

WebPixie calculates uptime as the share of monitored time your site responded successfully, using the industry-standard method that excludes periods when monitoring was not active. The basic formula is successful (up) time divided by total monitored time, multiplied by 100 (Uptime % = Up time ÷ Total monitored time × 100). Uptime monitoring checks your site at your plan's interval from monitoring locations such as London, Istanbul, and New York, and records each check as up or down. Time before a monitor was created, or while it was paused, is left out of the total rather than counted as downtime, so the percentage reflects only what WebPixie actually observed. A single network-error check does not count as down right away, because timeouts and connection errors go through up to 4 check attempts with exponential backoff before the failure is confirmed. On paid plans, verification checks from other locations also run before a network-related incident opens; a check that fails from one location but passes from the others is recorded and left out of the percentage instead of counting as downtime, which keeps a brief routing flicker from distorting the figure. The resulting percentage is what you compare against an SLA target, where the allowed downtime is the error budget the target permits. To translate a target like 99.9% into plain minutes for a day, week, month, or year, use the free uptime calculator. Check intervals and data retention depend on your plan, which you can compare on the pricing page.

Ready to catch downtime first?

Free plan, no credit card. Multi-location checks with cross-location verification on paid plans.