3.1Check frequency and timeouts
A check is one test of your service, such as one request to a URL. The check interval is how often obsrvly runs a check. The timeout is how long one check may wait for an answer. If no answer comes in time, the check fails.
Set the check interval and timeout#
- Select + new monitor, or open a monitor and select Edit.
- In the left column, find check interval. Enter a number and choose seconds, minutes or hours.
- If the form shows timeout, enter a number of seconds.
- Select create monitor → or save changes →.
A new form starts at a check interval of 60 seconds and a timeout of 10 seconds. If your plan's minimum is longer than 60 seconds, the interval starts at your plan's minimum instead.
Your plan's minimum interval#
Your plan sets the shortest check interval you can save.
The form shows your limit under the field, for example Your plan: every 30s or slower. If you enter a shorter interval, it shows Your plan checks at most every 30 seconds. Enter a longer interval to save.
Through the API, a too-short interval returns the error code failed_precondition. The message names your plan's shortest interval and the interval you asked for.
- The interval must be more than 0. Otherwise the API returns
invalid input: interval_seconds must be > 0. - When you edit a monitor, the plan minimum is checked only if you change the interval. A monitor that keeps an older, shorter interval can still be saved.
- If obsrvly suggests an interval for you, your plan's minimum still applies.
Types with a different schedule#
- Domain expiry: the create form has no check interval. The monitor is checked once a day. You can change the interval later on the edit page. A domain expiry monitor cannot be checked more than once an hour. If you try, the error tells you the minimum.
- Heartbeat: your job sends pings to obsrvly, so there is no check interval in the left column. You set how often pings should arrive in expected every. Chapter 5 covers heartbeats.
Timeout by monitor type#
The dashboard shows the timeout field for URL, API, multi-step API, TCP, UDP, ping, gRPC, WebSocket and browser monitors. It does not show it for DNS, TLS certificate, domain expiry and heartbeat monitors. Those use the default below.
| Monitor type | Default if no timeout is sent (API) | Longest timeout |
|---|---|---|
| URL | 30 seconds | 60 seconds |
| API | 30 seconds | 60 seconds |
| TCP | 10 seconds | 60 seconds |
| UDP | 10 seconds | 60 seconds |
| Ping | 10 seconds | 60 seconds |
| gRPC | 10 seconds | 60 seconds |
| WebSocket | 30 seconds | 60 seconds |
| DNS | 5 seconds | 60 seconds |
| TLS certificate, domain expiry | 10 seconds | 60 seconds |
| Browser | 30 seconds (for the whole script) | 120 seconds (for the whole script) |
If you set a timeout above the longest timeout, obsrvly uses the longest timeout. You do not get an error.
Dashboard and API differences#
| Setting | Dashboard | API |
|---|---|---|
| Timeout unit | Seconds | Milliseconds, in timeoutMs |
| Default timeout | 10 seconds | Per type, see the table above (send 0 or leave it out) |
| Timeout for DNS, TLS certificate, domain expiry | No field. The default applies. | You can send timeoutMs. Saving the monitor in the dashboard removes it. |
| Check interval | Required on the form | Required in intervalSeconds, except for domain expiry (defaults to once a day) |
On create, send timeoutMs in the request. On update, send it inside config (see 3.7).
Slow-response limit#
A slow-response limit marks a passing check as degraded when it takes longer than the limit. Degraded means the check passed but was too slow. A failed check stays failed.
- Open the monitor and select Edit. The field is on the edit page only, not on the create page.
- In the paging block, find degraded when slower than (ms) — blank for no limit.
- Enter a whole number of milliseconds, for example
2000. Leave it blank for no limit. - Select save changes →.
The field appears for URL, API, multi-step API, TCP, UDP, ping, gRPC, WebSocket and DNS monitors.
A degraded check shows a message like slow: took 2500ms, the limit is 2000ms.
Through the API, send degradedAfterMs with UpdateMonitor. Send 0 to remove the limit. To read it, look at degradedAfterMs on the monitor. 0 means no limit.
{"id": "<monitor-id>", "degradedAfterMs": 2000}