How to Monitor Website Uptime from Your iPhone

By Paul Snyman · Published April 23, 2026 · 9 min read

You launched a side project. Or you run a small business website that brings in real revenue. Or you maintain an internal tool that the team relies on every day. In all of these cases, you want to know the moment something goes down - not when a customer emails you, not when you happen to refresh the page, but the instant your monitoring catches the problem.

Traditionally, uptime monitoring meant signing up for a SaaS dashboard, configuring webhooks, and learning yet another tool. This guide shows you how to do it with push notifications going directly to your iPhone home screen, using PingKit Uptime Watch. The checks themselves run server-side from PingKit's backend, every five minutes with Guardian or once an hour for the free target - your iPhone and the free Mac Agent both just add and view the targets you want watched; the push alert reaches your iPhone when one changes state.

What Uptime Monitoring Actually Does

An uptime monitor performs three things on a schedule:

Sends an HTTP request to a URL you specify. Usually a GET request to your homepage, status endpoint, or health check.
Checks the response. Did it return in time? Is the status code in the expected range (typically 200–299)? Does the body contain the expected content?
Records the result and notifies you on failure. Successes go into a history log. Failures trigger a push notification.

That is the entire job. The value is not in the technology - HTTP requests are trivial - it is in the discipline of doing it consistently and surfacing the results where you will actually see them.

Why iPhone Monitoring Beats a Dashboard You Never Open

Most outage detection failures are not technical. They are attentional. The Grafana dashboard is open in a tab nobody is looking at. The SaaS monitoring service emails you, but the email lands in a folder you scan once a day. By the time you notice, the outage has been visible to users for an hour.

A push notification on your iPhone arrives in the only place you actually pay attention to. The lock screen. The notification banner. The badge on the app icon. You will see it within seconds, regardless of what device you are at, regardless of whether your laptop is open. For a solo founder, indie developer, or small team, this is the right level of monitoring.

What to Monitor

Start with the smallest set of endpoints that actually matter:

Your homepage. If this returns a 5xx, you have an obvious problem.
A health check endpoint. Most modern web frameworks expose /health or /healthz. This bypasses caches and verifies the application is actually running.
Critical user flows. The login page. The checkout page. The API endpoint your mobile app depends on. These are the things whose downtime translates directly into lost users or revenue.
Third-party dependencies. If your app cannot work without Stripe, Auth0, or your DNS provider, monitor those too. Your status page should reflect their status.

Resist the urge to monitor everything. Five well-chosen endpoints with frequent checks beat fifty endpoints checked rarely. Each false alarm reduces your willingness to react to the next one.

How Often Uptime Watch Checks Run

Uptime Watch does not ask you to pick an interval; the interval comes with your tier. With Guardian, each of up to ten targets is checked every five minutes. The free target is checked once an hour. Either way the check runs server-side from PingKit's backend - a scheduled job that sends a request to every target you have added, regardless of whether you added it from your iPhone or the Mac Agent. Neither the iPhone app nor the Mac Agent performs the check itself; both are just a front end for managing your target list and viewing results. When a target changes state, from up to down or back again, you get a push notification.

A five-minute cadence will not reliably catch a 90-second blip, an hourly one even less so, and neither is a substitute for the one-minute, multi-region checks a dedicated SRE platform offers. What it is good at is the thing most solo developers and small teams actually need: knowing within minutes on Guardian, or within the hour on the free tier, that a site is down, without babysitting a dashboard or configuring anything.

What Counts as "Down"?

Not every non-200 response is an outage. A useful monitor distinguishes:

Connection failed - DNS resolution failed, TCP connection refused, or TLS handshake failed. This is almost always a real problem.
Timeout - the server did not respond within the threshold (typically 10–30 seconds). Often means the application is overloaded or hung.
5xx error - the server received the request but failed to handle it. Application or upstream dependency problem.
4xx error - depends on context. A 404 on your homepage is bad. A 401 on an authenticated endpoint may be expected.
2xx but wrong content - the server responded successfully but the page is broken (e.g., returning a generic error page with status 200). A plain status check lets this slip through. With Guardian, Uptime Watch can require a keyword the page must contain (case-sensitive, exact text) or an exact status code, which catches the common version of it. It still reads one page, so keep an eye on your own logs and error tracking too.

Step-by-Step: Set Up Uptime Watch on iPhone

Your first URL is free for as long as you like, checked hourly, push notifications included, and Guardian raises the cap to ten targets checked every five minutes, which the Uptime Watch page sets out in full.

Install PingKit from the App Store.
Optionally subscribe to Guardian ($2.99/month or $24.99/year) for ten targets, five-minute checks, TCP port checks, keyword checks and 30 days of history. Your first URL is watched free without it.
Optionally install the free PingKit Mac Agent on a Mac on your network. It is a convenient way to manage your target list from your desktop, but it does not change how often checks run - that happens server-side either way.
Open the Monitor tab and tap into Uptime Watch.
Add your first endpoint. Enter the full URL (including https://) and pick a friendly name. With Guardian you can instead choose Port (TCP) and enter a public host and port, or add a keyword or expected status code to a website target.
Enable push notifications when prompted. Without this, alerts do not reach you.
Repeat for each endpoint. Add the homepage, health check, and any other critical URLs.
Test the alert. Temporarily change a URL to something that does not exist (e.g., https://example.com/404) and confirm you get a failure notification, within five minutes on Guardian or within the hour on the free tier.

Reading the Uptime History

After a few days, the history view starts to be useful. Each target has an hourly response-time chart covering its full history (7 days on the free tier, 30 days with Guardian), with red marking any hour that had a failed check. Look for:

Patterns of failures. Does the site go down at a specific time every night? Probably a backup job or batch process eating resources.
Slow response times. A 200 response in 8 seconds is technically up but functionally broken. Watch for response time creeping up over weeks - usually a sign the database is slowing down or you are accumulating debt.
Cluster events. Multiple endpoints failing simultaneously usually means infrastructure (DNS, CDN, host provider). Single endpoints failing usually mean application bugs.

What Uptime Watch Does Not Replace

For a solo developer or small team, Uptime Watch is enough. For larger operations you will eventually want:

Multi-region checks. Your site might be down for users in Europe but up from the one network a single-location check runs from. Dedicated services like Uptime Robot, Pingdom, or Datadog Synthetics check from multiple points of presence.
On-call rotations. If you have a team, PagerDuty or Opsgenie rotate alerts based on who is on call.
Status page automation. Tools that turn monitoring data into a public status.example.com page customers can subscribe to.

Uptime Watch fills the gap between "I have nothing" and "I have a full SRE platform". For a very large set of users, that gap is the right place to be.

The Real Win: Knowing Your Actual Uptime Number

Most small site owners overestimate their uptime. The site feels fine when they check it, so they assume it is always fine. After a month of automated monitoring, the real number is often 98% - meaning roughly 14 hours of cumulative downtime that nobody noticed.

This number is the data you need to make decisions: switch hosting providers, move to a CDN, harden a deployment process, or accept that 98% is fine for your use case. Without measurement, you are guessing.

Conclusion

Uptime monitoring used to be a hosted service you paid for and never opened. With PingKit Uptime Watch, it is a feature that pushes alerts the moment something goes wrong. Add the URLs that matter and let the alerts come to your iPhone, no dashboard, no interval to configure.

Get Notified the Moment Your Site Goes Down

Uptime Watch checks one endpoint free every hour, or ten every five minutes with Guardian, from PingKit's backend and pushes alerts straight to your iPhone when something changes.

Download Free on the App Store