Uptime
An uptime test (also known as a status check or availability monitor) is an automated process used to monitor the availability and performance of a website or web service. By continuously sending requests to your target URL, the system ensures your site is reachable and responding correctly.
How Uptime Testing Works
The monitoring system periodically acts as a client simulating either a mobile or desktop user and attempts to connect to your specified URL. It then evaluates the server's response against your predefined criteria.
- Request: The monitoring service sends an HTTP request to your server at set intervals.
- Response: Your server responds with a status code (like 200, 404, or 500) and the page content.
- Verification: The system compares this response against the Expected Result you configured to determine if the test passes or fails.
Configuration Options
When setting up a new uptime test in the dashboard you can customize several parameters to match your specific monitoring requirements.
Configuration Fields
| Field | Description |
|---|---|
Test Name | A descriptive label for your test (e.g., "Homepage Availability"). |
Test URL | The full web address (endpoint) you want to monitor. |
Tested Device | Choosing Mobile or Desktop ensures you are testing the version of the site served to that specific device type. |
Expected Result | The criteria used to define "success." (See details below). |
Defining an "Expected Result"
You have two primary methods for validating a successful connection:
- 200 OK: The test passes if the server returns a standard "success" HTTP status code (200). This indicates the server processed the request correctly.
- Contains: You can define a specific string (keyword, text, or HTML tag) that must be present in the page source for the test to pass.
π‘ Pro-Tip: A server can occasionally return a 200 OK status even if the page is completely blank or displaying a database error message. By using the Contains option to look for a specific piece of text (like your brand name or a footer link), you ensure the actual content is rendering correctly for your visitors.
Failure Logic and Alerting
To minimize "false positives" caused by temporary network jitters or momentary server blips, Webeyez follows a strict validation sequence before flagging an incident. This ensures that your team is only alerted to genuine, persistent downtime.
The Failure Verification Process
If an uptime test does not meet the expected result, the system triggers an automatic verification protocol rather than alerting you immediately:
[Initial Failure] ββ> (Wait 10s) ββ> [2nd Test Fails] ββ> (Wait 10s) ββ> [3rd Test Fails] ββ> [π¨ Webeyez Alert Sent]- Initial Failure: The first test fails to meet the expected criteria.
- Verification Period: The system automatically initiates a second and third test.
- Interval: These re-tests are conducted precisely 10 seconds apart.
- Threshold for Alert: Webeyez will only send out an alert after 3 consecutive failures. If either of the retry tests succeeds, the counter resets, and the site is marked as online.
Handling 403 Forbidden Responses
If your uptime test consistently fails with a 403 Forbidden status code, it indicates that your web server or a security firewall (WAF) is actively blocking the Webeyez uptime agents.
Note: Webeyez does not trigger alert notifications for 403 responses, as this is interpreted as an intentional block by your security configuration rather than a server outage.
How to Resolve 403 Errors
To allow Webeyez to monitor your site correctly, you must whitelist the following IP addresses in your server firewall or security service:
| IP Range | CIDR |
|---|---|
13.69.109.132 - 13.69.109.135 | 13.69.109.132/30 |
20.105.215.20 - 20.105.215.21 | 20.105.215.20/31 |
172.201.232.60 - 172.201.232.63 | 172.201.232.60/30 |
Once these addresses are whitelisted, the uptime agents will be able to successfully retrieve your page content.