Monitor uptime
Most uptime tools ping on their own clock, whether or not that matches how your infrastructure actually needs to be watched.
This uptime monitoring API works to your schedule instead: you register a monitor from your own automation, set how often it runs, and it checks the target on that cadence and calls your webhook when the status changes — so the watching happens for you rather than depending on someone staring at a dashboard.
Uptime checking on the schedule you set
Traditional uptime monitors run as a standing service on a vendor's default interval, and that model works well for some teams and poorly for others. Anyone already running their own scheduler, orchestrator, or cron infrastructure often wants to decide the cadence themselves: register a monitor, set how often it checks — every few minutes for a critical shop, hourly for a quieter page — and let it run on exactly the rhythm your infrastructure needs rather than a fixed interval you cannot change.
What the monitor does on each run
Registering a monitor with POST /web/uptime takes a target URL and a cadence; on each run it performs a reachability check — whether the endpoint responded, its status code, and how long it took to answer — and compares it against the previous state. You decide the interval entirely: every few minutes during a deploy window, once an hour in steady state, or whatever matches the endpoint's risk profile.
From wall-mounted pager alerts to programmable monitors
Uptime monitoring used to mean a pager going off because a human noticed a site was down; then it became dashboards and always-on external pingers. The next step is treating the monitor as a programmable building block rather than a fixed product — something your own systems register, whose cadence they set, and which returns a webhook when the state changes, on the schedule your infrastructure actually needs rather than a vendor's default interval.
Built for scripts, not dashboards
Registering the monitor is asynchronous: you receive a schedule_id immediately, and from then on a signed webhook fires whenever the status changes — the practical option for feeding an alerting system or status page automatically, rather than polling a dashboard by hand. That design fits naturally into a status page generator, an incident response runbook, or a deploy pipeline that reacts to a monitor going red.
One flat, predictable price
Each check costs a flat $0.002 per request, published with no hidden tiers, and there is no free tier or trial — access requires prepaid balance, which keeps the checking capacity fast and free of abuse. A failed check retries automatically up to three times before returning a clear error, and a task that ultimately fails is never charged.
What you can do with it
Post-deploy health monitoring
Register a monitor on a freshly deployed endpoint and get a webhook the moment it stops responding, so a regression surfaces as an alert instead of a support ticket.
Custom-interval infrastructure monitoring
Register a monitor for each critical endpoint at whatever cadence matches its actual risk profile, from every few minutes to daily.
Status page backend
Power a public or internal status page from the webhook a monitor sends when an endpoint's status changes.
Incident response verification
Keep a monitor on a recovering endpoint and let its recovery webhook confirm the service is back before you close out the alert.
FAQ
How is this different from a hosted uptime-monitoring dashboard?
It is a scheduled monitor, but you own the schedule: you set the exact cadence from your own automation and receive a webhook only when the status changes, instead of accepting a vendor's fixed polling interval and dashboard.
Is uptime monitoring free to try?
There's no free tier — free tiers get abused and slow everyone down. Access runs on a prepaid ForHosting KIT balance: top up from $10.00 (it never expires) and each request is charged at its published price, so a call with no balance returns HTTP 402. No subscription, no tokens, no invented credits, and a failed task is never charged.
What does the monitor send when something changes?
When a check's result differs from the previous one, a webhook delivers the change — for example the endpoint going from responding to unreachable, or its status code changing — with the schedule id and a timestamp.
How do I set up recurring uptime checks?
Register the monitor once with POST /web/uptime and set the cron interval you want; the API keeps running the check on that schedule for you, so you do not need your own cron to trigger each check.
Can I get alerted when a check fails?
Yes, configure a signed webhook and it fires as soon as a check detects the status has changed — for instance the endpoint going down — so your alerting system reacts on the next scheduled run after the failure.
Can I monitor many endpoints at once?
Yes, register one monitor per URL and each runs independently on its own schedule. To watch a whole list under a single monitor, the multi-target version is a better fit.
What happens if a check itself times out or errors?
The task retries automatically up to three times; if it still fails, you receive a clear error rather than an ambiguous result, and the failed attempt is not charged.
Is historical uptime data stored for me?
No, results are delivered and then deleted after the retention period, and are never used for training — building a history is on your side, typically by logging each webhook result.
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
One authenticated POST creates the task; the result comes back by webhook or a signed link. This capability is currently available through the API, not as an interactive Web tool.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/web/uptime \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://example.com"}'const res = await fetch("https://api.kit.forhosting.com/web/uptime", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"url": "https://example.com"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/web/uptime",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"url": "https://example.com"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/web/uptime", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"url":"https://example.com"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"url":"https://example.com"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/web/uptime", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"url": "https://example.com"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "web.uptime",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
timeout_sec | 30 |
max_crawl_pages | 25 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |