Yes, you can monitor a website you do not own, and it is completely ordinary practice. An external uptime check makes the same request a visitor's browser makes, from the public internet, with no access, credentials, or permission required. Agencies watch client sites this way, engineering teams watch the vendors they depend on, and procurement teams watch suppliers whose contracts contain uptime promises.
This article covers the three situations where monitoring someone else's site is entirely normal, the specific behaviours that turn a reasonable check into something you should not be doing, and the practical setup that keeps external monitoring useful and uncontroversial.
The three normal cases
Agencies and contractors watching client sites. A web agency responsible for a client's site frequently sets up monitoring before it has server access, sometimes before the client has finished granting anything at all. External checks need nothing from the client and answer the only question that matters during an incident: is the site reachable for customers right now. This is the most common case by a wide margin and nobody involved considers it unusual.
Teams watching their own dependencies. Modern applications lean on payment processors, authentication providers, mapping APIs, CDNs, and a dozen SaaS tools. When one of them fails, your application fails and your customers blame you. Watching the endpoints and status pages you actually depend on turns a confusing incident into a two second diagnosis, and it is how you find out about a vendor outage before the vendor's own status page updates.
Procurement and account teams verifying uptime claims. A supplier who committed to 99.9 percent availability in a contract has made a measurable promise. Independent monitoring produces your own record of whether it was kept, which is a considerably stronger position than accepting a vendor's self-reported figure during a renewal conversation.
Where the line actually sits
The distinction is not ownership, it is behaviour. A check that behaves like an ordinary visitor requesting an ordinary public page is unremarkable. Several behaviours take it somewhere else.
Frequency is the first. A public page checked once a minute is a rounding error in anyone's traffic. The same page checked every second from twenty locations is a load-generating event that the site's operators will experience as hostile, and it may well trip the same protections that stop genuine attacks. Depth is the second. Requesting a page is fine; crawling a site, harvesting its content, or hammering an expensive search endpoint is a different activity wearing the same clothes.
Authentication is the third and the clearest. Logging into an account you were not given, reusing credentials you obtained elsewhere, or probing past an access control is not monitoring, whatever the tool is called. Anything requiring you to get past a barrier the operator put up is outside what an external check should be doing. The fourth is side effects: never point a check at something that acts rather than reads. Submitting a form, starting a checkout, or triggering an email on someone else's site every five minutes generates junk for a stranger to clean up and will eventually be noticed.
Terms of service also exist, and some sites prohibit automated access explicitly. That is a question for the site's terms and, if the stakes justify it, for a lawyer rather than for a monitoring guide. This article describes what is technically possible and conventionally accepted, which is not the same thing as legal advice.
Setting it up so it stays uncontroversial
A few choices keep external monitoring firmly in the reasonable category. Use a sensible interval, which for a third party site means one to five minutes rather than anything faster. Point the check at a lightweight, public page, ideally the homepage or a documented health or status endpoint, and never at checkout, search, login, or any route that costs the operator real money to serve.
Identify yourself. A descriptive user agent naming your organisation and giving a contact address costs nothing and converts a mysterious pattern in someone's logs into an easy conversation. Operators very rarely object to monitoring they can identify; they object to unexplained automated traffic, which is a different thing.
Watch the vendor's status page alongside the site itself, because a status page tells you what the operator has acknowledged while your check tells you what you are actually experiencing, and the gap between those two is often the most useful signal you have. And keep your alerting proportionate: a third party outage is information you need, but it is rarely something you can fix, so route it somewhere people will see it rather than somewhere that wakes them. Our guide to checking whether a website is down covers the manual version of the same investigation.
What external monitoring can and cannot tell you
An external check answers one question well: could a client on the public internet get a valid response from this URL at this moment. That is genuinely valuable, and for a site you do not own it is very close to the complete set of what you are entitled to know.
It is worth being clear about the limits. You cannot see the site's error rate, its server metrics, its database health, or its internal alerts. You cannot distinguish a total outage from a failure affecting only your region unless you are checking from several locations, which is a strong argument for doing so. You cannot tell whether a slow response is the site struggling or the network between you and it. And a 200 status code proves the server answered, not that the answer was correct, which is why an assertion on page content matters even more when monitoring something you cannot inspect from the inside. If the page returns successfully but no longer contains the text it should, something is wrong that a status code will never reveal.
Common mistakes in monitoring a site you don't own
Checking far too often. A one second interval against someone else's site is load generation, not monitoring. One to five minutes gives you everything useful without becoming a problem for the operator.
Pointing checks at expensive or transactional pages. Search, checkout, and login are costly to serve and often stateful. Use the homepage or a documented status endpoint instead.
Running anonymous automated traffic. An unidentified pattern in a stranger's logs invites blocking. A descriptive user agent with a contact address turns it into something they can ask you about.
Assuming a 200 means the site works. Servers return healthy status codes for error pages, maintenance notices, and half-rendered templates. Assert on expected content, especially when you cannot see inside.
Treating vendor alerts like your own. You cannot fix a supplier's outage. Route those alerts to a channel people read rather than to whatever wakes the on-call engineer.
FAQ
Do I need permission to monitor someone else's website?
Not for ordinary external checks on public pages, which are technically identical to a visitor loading the page. Permission becomes relevant with authenticated checks, high frequency traffic, or anything a site's terms of service specifically prohibit.
Can I monitor a competitor's uptime?
Technically yes, using the same public checks anyone could run. Keep the frequency modest and stay on public pages, and be aware that some sites restrict automated access in their terms.
How do I monitor a vendor my application depends on?
Check the specific endpoint you actually call rather than the vendor's marketing site, monitor their status page alongside it, and route the alerts to a channel your team reads rather than to the on-call rotation.
What can external monitoring not tell me about a site I don't control?
Anything internal: error rates, server health, database state, or the cause of a slow response. It tells you whether a public client got a valid response, which for a third party is usually the only thing you can know.
Closing thought
The question is rarely whether you may monitor a site you do not own, because an external check is an ordinary web request and the answer is almost always yes. The better question is whether the check you have configured behaves like a visitor or like a nuisance, and that is decided by frequency, by which page you point it at, and by whether you left a way for the operator to identify you.
Get those right and external monitoring becomes some of the most useful information available to an agency or a team with dependencies. Odown runs checks against any public URL from seventeen locations worldwide, with content assertions, configurable intervals, and alerts through Slack, Teams, PagerDuty, email, or SMS. If you are responsible for sites or services you do not host, website monitoring starts at twelve dollars a month with a fourteen day trial and no card required.
