# HTTP and Keyword Monitors

> Monitor a website or API with Edesy OnCall - HTTP method, expected status codes, keyword present or absent, timeout, fail threshold and check interval, and what counts as down.

Source: https://edesy.in/docs/oncall/monitors/http-and-keyword

An **HTTP** monitor requests a URL on a schedule and checks the status code. A **Keyword** monitor does the same and also checks that a word or phrase is in the response (or is not). When a check fails enough times in a row, an incident opens and your escalation policy starts calling.

## Settings

| Field | Values | Default |
|---|---|---|
| `url` | A full `http://` or `https://` address | Required |
| `method` | `GET`, `HEAD` or `POST` | `GET` |
| `expect_status` | `2xx`, a code such as `200`, or a list such as `200,204` | `2xx` |
| `keyword` | Text that must appear in the response body (Keyword monitors) | Required for Keyword |
| `keyword_absent` | `true` = alert when the text **is** found (for example "error") | `false` |
| `interval_sec` | How often to check: from your plan's minimum up to 86,400 (24 hours) | 300 on Free, 60 on paid plans |
| `timeout_ms` | 1,000 to 30,000 | 10,000 |
| `fail_threshold` | Failed checks in a row before the monitor is down: 1 to 10 | 2 |

The minimum interval depends on your plan: 5 minutes on Free, 60 seconds on Starter, 30 seconds on Pro. See [Plans and Billing](https://edesy.in/docs/oncall/getting-started/plans-and-billing).

## What counts as a failure

- The connection fails or times out.
- The status code doesn't match `expect_status`.
- For Keyword monitors: the keyword is missing (or, with `keyword_absent`, present). The match is a case-sensitive text match in the first 1 MB of the body.
- More than 5 redirects. Up to 5 redirects are followed, and the final response is checked.

After a failed check that doesn't reach the threshold yet, OnCall checks again after about 20 seconds instead of waiting a full interval, so a real outage is confirmed quickly and a one-off blip doesn't page anyone.

When a check passes again, the monitor goes back up and the incident resolves itself. See [Acknowledge and Resolve](https://edesy.in/docs/oncall/alerts/acknowledge-and-resolve).

## Good to know

- Checks identify themselves with the User-Agent `EdesyOnCall/1.0 (+https://oncall.edesy.in)`. Allow it through your firewall or bot protection.
- Private and local addresses (for example `192.168.x.x`, `10.x.x.x` or `localhost`) are refused. Monitor a public URL, or use a [heartbeat](https://edesy.in/docs/oncall/monitors/heartbeat) from inside your network.
- Each monitor shows its last check, response time and 24-hour uptime in the portal.
- Pause a monitor during planned work; paused monitors don't open incidents.

## Examples

| Goal | Type | Settings |
|---|---|---|
| Homepage is up | HTTP | `url: https://example.com`, `expect_status: 2xx` |
| Health endpoint is healthy | Keyword | `url: https://api.example.com/health`, `keyword: "ok"` |
| Checkout page shows no error | Keyword | `url: https://shop.example.com/checkout`, `keyword: "Something went wrong"`, `keyword_absent: true` |
| Lightweight check | HTTP | `method: HEAD`, `expect_status: 200,204` |

## FAQ

**Is the keyword match case-sensitive?**
Yes. "OK" and "ok" are different keywords.

**Can I check an internal service that has no public URL?**
Not with an HTTP monitor; private addresses are refused. Run a small script inside your network that pings a [heartbeat monitor](https://edesy.in/docs/oncall/monitors/heartbeat) when the service is healthy.

**Does OnCall check SSL certificate expiry?**
No. An invalid certificate makes an HTTPS check fail, but expiry dates are not tracked in advance.

**Where do checks run from?**
From Edesy's monitoring service. Checks are not run from several regions at once.