URL monitoring made simple: watch any page for anything

Somewhere in every company there is a web page that somebody checks by hand. The booking page before a holiday weekend. A supplier's price list. The regulator's page where the new rule will appear "any day now". A competitor's pricing table. Your own checkout, after the last update, just to be sure.

Checking by hand works right up until the one morning you forget, which is always the morning it mattered. URL monitoring is the boring, wonderful fix: a machine that looks at the page for you, on a schedule, and only speaks up when something is worth saying.

The interesting news is how easy that machine has become to get. It used to be a subscription with a per-check price, or a script one engineer wrote and everyone else was afraid to touch. Today it is a sentence. You describe what you want watched, and an AI assistant with its own server builds the watcher, keeps it running, and hands you a link.

Quick answer

Tell your assistant four things: which pages to watch, what to look for, how often, and who to tell. With Server4Agent connected to the chat app you already use, the assistant builds a watcher that checks the pages on that schedule, remembers what it saw, alerts you by email, Slack, or wherever you asked, and gives you a private status page you can open on your phone. There is no monitoring vendor to sign up for, no server to rent, and no code to look after. If you later want to know how it works underneath, the technical half of this post walks through it.

Key takeaways

• "Monitoring a URL" covers five different questions: is it up, is it fast, did it change, does it still say X, and did a number cross a line. Name the question and the rest follows.
• A good request reads like a message to a diligent colleague: the pages, the condition, the schedule, and where the alert should go.
• The first version takes minutes. The good version confirms before alerting, alerts only when something changes, and respects quiet hours, and you get those by asking for them.
• Everything starts private unless you ask otherwise. The status page is yours until you decide the team, or the public, should see it.
• It is not a replacement for a full monitoring platform run by an engineering team. It is the watcher you would never have gotten around to setting up otherwise.

What "monitor this URL" actually means

The phrase hides several different jobs. Deciding which one you mean is most of the work, and it takes about ten seconds.

Most real requests combine two of these. "Is our status page up, and does it still say all systems operational" is an up check plus a still-says check. "Watch the competitor's pricing page" is a change check where you probably only care about the price column. Say both halves and you will get both halves.

How to ask for one

If you can write the message you would send to a diligent colleague, you can write the monitor. A good brief names four things: the pages, the condition, how often, and where the alert should go.

Here is how it played out for the operations lead at Bluewater Ferries, a small coastal operator with one booking site and a lot riding on it in August. Her message was: "Check our booking page and the payment page every two minutes. If either one fails or takes longer than three seconds, message the ops Slack channel. Keep a history I can look at, and give me a simple page showing the last 24 hours."

A few minutes later her assistant replied with a private link. The page listed both URLs, a green or red badge, the last check time, and a row of tiny bars for the past day. She opened it on her phone, replied "add the timetable page too, and do not alert me between 1am and 5am unless it has been down for ten minutes", and the same link updated. Nobody at Bluewater opened a code editor, rented a server, or compared monitoring vendors.

That exchange is the whole method. The non-technical guide to shipping real tools from chat covers connecting the assistant once; from then on, a watcher is a request rather than a project. If you would rather start from a proven prompt, the URL uptime monitor and price and job watcher templates each come with setup notes and a live example.

A few requests that work well exactly as written:

• "Watch these six landing pages every five minutes. Alert me by email on the first failure and again when they recover."
• "Every morning at 8, look at this planning-portal page and email me what changed since yesterday."
• "Check that our app's health page says 'ok' every minute. Slack me if it says anything else."
• "Track this job listing page hourly and message me when a posting mentions 'remote' and 'senior'."

Why this got easy

A watcher is not hard to write. It has always been awkward to keep running. Four things have to sit together and stay alive:

• Something that looks at the page and reads what came back.
• A schedule so it happens without anyone remembering.
• A memory so "changed" and "still down" mean something, and so there is a history to look at.
• A voice so it can tell you: email, Slack, a page you can open.

Historically each of those lived somewhere different: a script on a laptop that went to sleep, a scheduled job on a server someone else owned, a spreadsheet for history, and an alert that meant setting up yet another account. The reason URL monitoring feels easy now is that the assistant's server holds all four at once. It writes the checker, schedules it, keeps the history, logs every run, and serves the status page from the same place. It is the same reason AI agents need persistent workspaces: a watcher that lives inside a chat message dies with the message. One that lives on a server is still checking next Tuesday.

What separates a good monitor from a noisy one

The first version of any monitor is too eager. The second version is the one people keep. The difference is a handful of habits, and you get them by naming them in the request rather than discovering them at 3am.

• Confirm before alerting. Check again once or twice after a failure so a single hiccup does not wake anyone.
• Alert on changes, not on every check. One message when it goes down, one when it recovers, silence in between.
• Quiet hours with an override. No alerts overnight unless the outage lasts longer than a limit you set.
• Be polite to the other site. Sensible intervals and no hammering. Checking someone else's page every ten seconds is how you get blocked.
• Watch the part that matters. Compare the price column, not the whole page with its rotating banner and timestamp footer.
• Keep history and show it. A red badge is a fact; a chart of the last week is a story.

A request that includes those lines looks like this, and it is still a paragraph, not a spec:

Monitor these URLs every 5 minutes: [list]. Treat a check as failed only after two consecutive failures. Send one Slack message when a URL fails and one when it recovers. Between 23:00 and 06:00, only alert if it has been down for 15 minutes. Never check more often than the interval. Keep 30 days of history and show a 7-day chart per URL on the status page.

Where this stops and a full monitoring platform starts

An assistant-built monitor is the right tool for the pages a team cares about and would otherwise check by hand: a launch, a pilot, a supplier, a competitor, a compliance page, a handful of endpoints. It is not a substitute for the deep monitoring, on-call rotations, and contractual status pages that engineering teams run for production systems. If you already have that, keep it. Use the assistant for everything that platform was never going to be pointed at, and for the checks that live outside your systems entirely, like the other company's pricing page.

The pleasant surprise is how much falls into that second bucket. Most pages worth watching were never going to justify a vendor evaluation. They justify one message.

For the technical reader: what the agent builds underneath

Everything above is the whole story for most people. If you are an engineer, or just curious, here is what happens on the server after the prompt lands. None of it is exotic, which is exactly the point.

A check function. The core is a few dozen lines that fetch a URL with a timeout, note the status code and elapsed time, and evaluate the condition. For a content check it looks for a phrase or a CSS selector; for a value check it parses a number and compares. A stripped-down version reads like this:

import time, httpx

def check(url, must_contain=None, max_seconds=3.0):
    started = time.monotonic()
    try:
        r = httpx.get(url, timeout=10, follow_redirects=True)
        elapsed = time.monotonic() - started
        ok = r.status_code < 400 and elapsed <= max_seconds
        if must_contain and must_contain not in r.text:
            ok = False
        return {"url": url, "ok": ok, "status": r.status_code, "seconds": round(elapsed, 3)}
    except httpx.HTTPError as err:
        return {"url": url, "ok": False, "error": str(err)}

A schedule. The agent either registers a cron entry for interval checks or runs a small always-on process for sub-minute ones. Every long-running process on the server appends to its own log file in the project folder, which is what the get_logs tool reads back when you ask "what did the monitor do overnight?".

A memory. Results go into a small SQLite database or a JSON file in the project workspace. That is what makes "changed since last time" and "down for ten minutes, not just one failed check" possible, and it is what the history view on the status page is drawn from.

A voice. Alerts go out through whatever destination you named. A Slack webhook URL or an email API key is stored as a project secret (write-only, so it never appears in the code, the logs, or the chat) and read from the environment at send time.

A page. A tiny web app on the project's managed port renders the current state and the history. It is reachable at the project's own subdomain, private by default, and you flip it public or team-only when you are ready. The habit of reviewing before publishing is covered in private by default.

Driving it from MCP

If you drive this from the MCP side rather than a chat app, the tool sequence is short. Create a project from the url-uptime-monitor template with the alert secret attached (the template publishes by default, so pass visibility explicitly to keep it private while you review), send the prompt, poll the run, read the logs, then open it up to the team when you are happy. Each block below is one tool call with its arguments:

{ "tool": "create_project", "server_id": "srv_4k2m", "template": "url-uptime-monitor",
  "visibility": "private",
  "secrets": [{ "key": "SLACK_WEBHOOK_URL", "value": "https://hooks.slack.com/services/..." }] }

{ "tool": "prompt", "server_id": "srv_4k2m", "project_id": "prj_9x7c",
  "prompt": "Check https://book.bluewater.example and https://pay.bluewater.example every 2 minutes. Post to the SLACK_WEBHOOK_URL secret when a check fails or takes longer than 3 seconds, and again when it recovers. Keep 30 days of history and serve a status page." }

{ "tool": "get_run", "server_id": "srv_4k2m", "run_id": "run_2f8p" }

{ "tool": "get_logs", "server_id": "srv_4k2m", "project_id": "prj_9x7c", "lines": 100 }

{ "tool": "update_project", "server_id": "srv_4k2m", "project_id": "prj_9x7c",
  "visibility": "public", "access": "team" }

Driving it from the Python SDK

The same thing from a script or a CI job:

from server4agent import Server4Agent

client = Server4Agent()  # reads SERVER4AGENT_API_KEY
server = client.servers.create(tier="small")

task = server.tasks.create(
    "Check https://book.bluewater.example every 2 minutes. "
    "Alert the SLACK_WEBHOOK_URL secret on failure or when response time exceeds 3s. "
    "Keep 30 days of history and serve a status page."
)
task.wait()
print(task.status, task.result)

The full tool table is in the MCP integration guide, and the SDK examples live in the SDK docs.

Checks engineers forget they can ask for

Once fetching on a schedule is free, the interesting monitors are the specific ones. All of these are a sentence away:

For pages that render with JavaScript or sit behind a login, ask for a browser-kind server; the agent drives a real browser instead of fetching raw HTML. It costs more per check, so reserve it for pages that actually need it. And whatever the check, keep a descriptive user agent and respect the target's rate limits; the politeness advice above applies twice as hard to anything automated.

Start with the page you check by hand

Pick the page you already open every morning "just to see". Describe what you look for when you open it, how often you would want a machine to look instead, and where the news should arrive. Send that message. If you have not connected an assistant yet, the integrations page has the current steps, or you can get early access and make the first thing you build the thing you will never have to check again.

FAQ

How often can it check?

As often as you like, within reason. Every minute is normal for your own pages. For other people's pages, be considerate: every 15 minutes to an hour is polite, and the agent will honor whatever interval you specify. Very high frequencies cost more and can get you blocked by the other site.

Can it watch pages that need a login or render with JavaScript?

Yes. Ask for a browser-kind server and describe the login steps; the agent drives a real browser session. Store credentials as project secrets, never in the prompt.

Where do alerts go?

Anywhere with an address: email, a Slack channel through an incoming webhook, a generic webhook your own systems receive, or just the status page if you would rather pull than be pushed.

What happens to the history if I stop paying attention?

It keeps accumulating on the server, capped at whatever retention you asked for. The monitor keeps running until you stop it, and the project's logs are always there to answer "what happened last night?".

Is this the same as the uptime monitor demo?

That post shows one build from prompt to live URL. This one is about the broader category: what URL monitoring means, the kinds of checks worth asking for, and how to phrase them so the first version is the one you keep.

Related reading

• From prompt to live URL: uptime monitor
• The first tool you should ask your AI assistant to build
• Why AI agents need persistent workspaces
• Share an internal tool with your team, not the public

External references

• MDN: HTTP response status codes
• RFC 9110: HTTP semantics
• crontab(5) manual page