Monitor / HTTP Ping

HTTP Ping monitor

An HTTP Ping monitor is a dashboard-configured endpoint check, independent of any SDK. You give Onelo a URL; Onelo's backend calls it on a schedule, decides pass/fail from the response, and records every check. The result lands in the same Feature Health table as your SDK-instrumented features, with the same alerts and incidents. Use it for things you can't — or don't want to — instrument with code.

Ping vs SDK — which one

Onelo Monitor has two ways to feed Feature Health. They answer different questions:

	SDK Feature Health	HTTP Ping monitor
What it watches	A named code path inside your app, via onelo.monitor.track() / event().	A URL you configure in the dashboard — from outside your app.
Where it runs	In your app / backend (the SDK reports runs).	On Onelo’s backend (a scheduler calls your URL).
Needs code	Yes — install the SDK and instrument the path.	No — paste a URL in the dashboard.
Best for	Real user traffic, error correlation with releases / flags / users.	Uptime of an endpoint, a health route, a marketing site, or a third-party API you depend on.

They're complementary. Instrument the flows that matter with the SDK for rich per-run detail; add a ping for the "is this URL up?" checks you can't reach from inside your code.

How it works

You configure it once

In the dashboard, open Monitor → Feature Health → + Add HTTP Ping. It is stored as a row in monitor_features with type = 'http_ping' and your settings in itsconfig.

A scheduler fires it when due

Onelo's backend runs a job every minute. Each monitor fires only when now − last_check ≥ intervalMins, so a 15-minute monitor checks every 15 minutes regardless of the 1-minute tick.

Onelo calls your URL

It sends your chosen HTTP method to the URL (with any headers / body / auth you set), with a 10-second timeout.

It decides pass or fail

A check is OK when the response status equals your Expected status and — if you set Body contains — that substring appears in the response body. Anything else (wrong status, missing substring, timeout, connection / DNS error) is a failure.

The result is recorded

Each check writes a row to monitor_checks: pass/fail, the status_code, the response latency in duration_ms, and an error string on failure. That drives the monitor's status, latency and history in Feature Health.

Configure a monitor

The fields on the Add HTTP Ping form:

Field	What it does	Default
Name	How the monitor appears in Feature Health. Must be unique within the app.	—
Method	One of `GET` `HEAD` `POST` `PUT` `PATCH` `DELETE`.	`GET`
URL	The endpoint to call. Must be a public `http(s)` address — see Security below.	—
Request body (JSON)	Sent with the request whenever set — regardless of method. Must be valid JSON.	none
Expected status	The HTTP status code that counts as success.	`200`
Body contains	Optional substring that must appear in the response body for the check to pass.	none
Interval	How often to check (`1` / `5` / `15` min in the UI). Your plan sets the minimum — see Plans & limits.	`5 min`

Authenticating the ping

If your endpoint is behind auth, pick one of four modes in the form's Authentication box. Header values and the pre-auth login body are stored encrypted at rest (AES-GCM). The main Request body field is stored as-is — keep secrets in headers or the pre-auth step, not in the request body.

Mode	What Onelo sends	Use when
None	Nothing extra.	The endpoint is public.
Static headers	Fixed header key/value pairs you enter (e.g. an API key header).	A long-lived token or key that doesn’t expire.
Pre-auth step	Logs in first, then injects the returned token into the real request (see below).	The endpoint needs a short-lived token you fetch by logging in.
Onelo credential	A Monitor Credential’s header + token, injected by the scheduler.	You want a token you manage in one place and your endpoint can verify came from Onelo.

Pre-auth step — Onelo calls a login URL before each ping, pulls a token out of the JSON response, and sets it as a header on the main request. You provide:

Setting	Meaning	Default
Auth URL + method	Where to log in. Method is `GET` / `POST` / `PUT` / `PATCH`. Also SSRF-checked.	`POST`
Auth body (JSON)	Optional JSON sent to the auth URL (e.g. client id / secret).	none
Token path	Dot-path to the token in the JSON response, e.g. `access_token` or `data.token`.	—
Header name	The header the token goes into on the main request.	`Authorization`
Prefix	Put in front of the token, so the header is `headerName: prefix + token`.	`Bearer`

Onelo credential pulls from Credentials → Monitor (create one there first). The scheduler injects that credential's header and token on every ping and stamps its last used time. Because you hold the same token, your endpoint can verify the request really came from Onelo. A revoked credential makes the check fail with credential not found or revoked.

Status, latency & history

In Feature Health a ping monitor shows its URL under the name, a HTTP Ping type, its latest status, error rate and last-checked time. Expand it (Runs) for a sparkline over the selected time range and the recent check log with per-check latency. Ping status is its own short scale:

Status	Meaning
`no_data`	No checks recorded yet (just created, or never ran).
`degraded`	The latest check failed, or the error rate over the last 200 checks is ≥ 10%.
`ok`	The latest check passed and the error rate (last 200 checks) is below 10%.

A ping monitor never shows down. Unlike SDK features (which have a configurable down threshold), a ping resolves only to no_data / degraded / ok — a failing endpoint reads as degraded. See Reference.

Alerts & incidents

Ping monitors use the same alerting as SDK features. Open the monitor's feature page → Configure alert to set an error-rate threshold and a time window. When the window's error rate crosses the threshold an incident opens; it auto-resolves when checks pass again and reopens if the failures return. Email and in-app notifications fire per your alert settings. Full lifecycle in Alerts.

Security (SSRF)

Onelo will only call public endpoints. Both the ping URL and any pre-auth URL are validated before each request: the scheme must be http or https, and the hostname must resolve to a public IP. Loopback, private (RFC-1918), link-local, multicast, reserved and unspecified addresses are rejected — so you can't point a monitor at localhost, 127.0.0.1, 169.254.x.x or an internal 10.x / 192.168.x host. A blocked URL simply doesn't run. One known limit: the hostname is resolved once at validation time, so DNS-rebinding (a record that changes between validation and the actual request) is not mitigated.

Plans & limits

Limit	Free	Pro	Business
Minimum interval	15 min	1 min	1 min

HTTP monitors have their own count per plan, apart from the feature names the SDK registers with track(): a ping never uses up a tracked-feature slot, nor the other way round. How many of each your plan allows is on the features page, read live from the plans.

Both are enforced when you create a monitor: adding one past your plan's count is rejected ("HTTP monitor limit reached for your plan", with a link to your plans), and choosing an interval faster than your plan allows is rejected ("Minimum ping interval for your plan is N minutes") — so on Free, pick 15 min. Ping check results follow the same retention as the rest of Monitor (Free 7d, Pro 30d, Business 90d).

Managing a monitor

Create from + Add HTTP Ping; remove from the monitor's row (Remove, with a confirm). There is no in-place edit in this version — to change a monitor's URL, interval or auth, remove it and add it again. Its check history is tied to the monitor name, so re-creating with the same name keeps a continuous view.

Dashboard→

Where ping monitors live alongside Feature Health and incidents.

Alerts→

Thresholds, incidents, auto-resolve and reopen.