How to Get Alerts When a Website Returns an Error

To get alerts when a website returns an error, create an HTTP or HTTPS uptime monitor for the URL that matters, set how often it should check, and connect a notification channel that reaches the person responsible. If the problem could be a broken page that still returns a successful HTTP status, add a content check. If the critical path depends on JavaScript, login, or user interaction, add a browser-based transaction monitor too.

An HTTP monitor periodically requests a URL and can mark it down when it does not respond or returns an error status code. It is a useful first signal, but it does not necessarily reproduce what a visitor sees in a browser. For example, Google Cloud documents that public uptime checks do not load page assets or run JavaScript.

1. Choose what to monitor

Start with the failure that would matter most to your users or team. Monitor a URL that represents a service or a critical user path:

Homepage: useful for detecting broad site availability problems.
Login page: checks whether the public login route responds. It may not verify that signing in works.
Checkout or form endpoint: checks an important path, though a basic HTTP request may not complete the whole transaction.
API endpoint: checks whether a service URL responds under the monitor’s configured conditions.
Important page content: use a content or keyword check if the page could respond successfully while showing an error, empty state, or missing content.

Monitor a small set of meaningful URLs first. Adding checks for every route can create noise without telling you which service or user journey failed.

2. Configure an HTTP(S) uptime monitor

Enter the full URL. Include the correct scheme, such as https://, and the path you want checked.
Choose the check type. For a public page or endpoint, an HTTP(S) monitor is a practical starting point. Providers may also offer TCP or other checks.
Set the interval. The interval controls how often the monitor requests the URL. A shorter interval can detect a failure sooner, but the actual alert time also depends on provider detection and notification behavior.
Set the expected result, if supported. Configure the status or response criteria that indicate health. If the provider supports a required text or keyword, use it when a successful status alone would not prove the page is usable.
Select monitoring locations, if available. Checks from multiple regions can help distinguish a broad outage from a location-specific connectivity issue.
Save the monitor and review its reported state. Confirm that the configured URL and criteria represent the intended check.

UptimeRobot’s HTTP monitor setup guide describes periodically requesting a URL and marking it down when it fails to respond or returns an error status code. Provider options and interfaces can change, so check the current documentation for the service you use.

3. Connect an alert channel

Choose a channel that the responsible person actually monitors, and make sure the notification route has a current recipient. Document who owns the alert and what the first response should be.

Depending on the monitoring provider, channels can include email, SMS, voice calls, push notifications, Slack, PagerDuty, or other integrations. For example, UptimeRobot lists email, SMS, voice calls, and integrations; Google Cloud’s uptime monitoring quickstart describes notification channels including email, Slack, PagerDuty, and Pub/Sub.

Consider configuring a delay, repeat policy, or maintenance window where the provider supports it. A short delay or recurrence policy can reduce noise from transient failures; maintenance windows can prevent planned work from generating routine incident alerts. Make sure those settings still give your team enough time to respond to a real outage.

4. Add checks for failures an HTTP response can miss

Check expected content

A URL can return a nominal response while the page is blank or missing important content. If your provider offers keyword monitoring, configure a phrase that should appear or a phrase whose appearance signals a problem. UptimeRobot describes checks that alert when selected text appears or disappears. Choose text that is stable enough to avoid alerts caused by routine copy changes.

Monitor the actual browser journey

Use browser-based transaction monitoring when health depends on JavaScript execution, rendered content, or interaction. Examples include signing in, submitting a form, or completing checkout. A public uptime check can establish that a URL responds under its configured conditions without testing the whole visitor experience. Better Stack describes transaction monitoring with Playwright in a real Chrome browser; compare supported journeys, diagnostics, alert channels, and current cost or limits before choosing a provider.

Use cloud-native checks when they fit your setup

If your team already operates in Google Cloud, its public uptime checks can test publicly accessible HTTP, HTTPS, or TCP targets and can be attached to an alerting policy. Note the documented limits: public checks do not load page assets or execute JavaScript, and the default configuration does not include authentication. Review the Google Cloud uptime checks documentation for configuration details.

5. Validate the alert path

After configuring the monitor and its notifications, confirm that the selected channel reaches the right recipient and that the recipient knows what the alert means. Keep the monitor URL, expected status or content, owner, and response instructions current. If your provider offers a way to test notifications or simulate a check, use its documented procedure.

Review the monitor when a page moves, authentication changes, content is redesigned, or ownership changes. An alert that points to an obsolete URL or an unmonitored inbox does not help with incident response.

HTTP checks versus browser checks

Check	Useful for	What it may miss
HTTP(S) uptime check	Periodic availability checks for a public URL or endpoint	JavaScript errors, missing assets, and whether a user can complete a workflow
Content or keyword check	Detecting missing expected text or the appearance of known error text	Interactive failures and problems not reflected in the selected text
Browser transaction check	Testing rendered pages and interactions such as login or form submission	Anything outside the specific scripted journey and its configured conditions

Performance, reliability, and cost considerations

Detection time: the check interval is one part of alert timing. Provider detection rules, notification delays, and repeat policies also affect when a person is notified.
Coverage: one URL only represents that URL under the configured check. Use additional checks for distinct critical services or journeys, and consider multiple regions when location-specific failures matter.
Alert noise: transient network errors can trigger notifications. Use provider-supported delay or recurrence settings thoughtfully, and avoid criteria that are too sensitive to routine content changes.
Check load: monitoring makes repeated requests to your service. Set an interval appropriate to the importance of the endpoint and your operational constraints.
Cost: plans and limits vary by provider and can change. Compare the current interval, number of monitors, locations, browser transactions, retention, integrations, and notification options against your needs.
Independent signal: an external monitor can help identify reachability problems from outside your application environment. It does not replace application logs, metrics, or investigation into the underlying cause.

Troubleshooting website error alerts

Symptom	Likely cause	What to check
No alert arrives	The contact, integration, or notification policy is missing or out of date.	Review the monitor’s alert settings, recipient, and provider notification status. Use a documented notification test if available.
The monitor says down, but the page opens for you	The monitor may be checking a different URL, status criterion, or network location.	Verify the full URL, expected response, and selected regions. Compare from the same conditions where possible.
The monitor says up, but users see a broken page	The endpoint responds, while JavaScript, assets, or application behavior is failing.	Add a content check or a browser-based transaction check for the affected journey.
The page is blank but the check is green	A successful HTTP response does not guarantee useful page content.	Configure a keyword/content check or test the rendered page in a browser monitor.
Alerts repeat during planned work	The maintenance window or notification suppression is absent or misconfigured.	Review the provider’s maintenance window and recurrence settings for the affected monitor.
A login or protected page cannot be checked	A public check may not include authentication by default.	Check the provider’s authentication support and configuration. Google Cloud documents that its default public uptime check does not include authentication.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server, not an uptime alert monitor. Use it when you need a screenshot of a page for inspection or an AI agent workflow. Its API accepts a URL and returns an image or PDF; see the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners, newsletter popups, and chat widgets are removed before the screenshot; each cleanup step can be turned off.
Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed. The response includes X-Page-Verdict and X-Billed headers.
An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents.
The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

FAQ

How do I monitor the uptime of a website?

Create an HTTP(S) monitor for the URL, choose its interval and health criteria, then attach an alert channel. Add content or browser checks if the page’s content or interactions matter.

Can an uptime check tell me whether checkout works?

A basic HTTP check can confirm that a configured URL responds, but it may not complete checkout. Use a browser-based transaction check for the steps whose success depends on rendered content and interaction.

Should I monitor the homepage or an endpoint?

Choose the URL that best represents the failure you need to detect. A homepage can signal broad availability; an endpoint or transaction check can represent a specific service or user journey.

Will a screenshot API notify me when my site is down?

No. ScreenshotNeo captures a page from a URL; use an uptime monitoring service to check periodically and send error alerts.