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 the other way around: you call it on your own schedule, from your own automation, and it returns status, response time, and reachability for that exact moment — nothing running in the background you did not ask for.
Uptime checking without a always-on daemon
Traditional uptime monitors run as a standing service, pinging endlessly whether you need the data at that instant or not, and that model works well for some teams and poorly for others. Anyone already running their own scheduler, orchestrator, or cron infrastructure often wants the opposite: a single, precise check they trigger themselves, fit into a pipeline, or run right after a deploy rather than a black-box monitor polling silently in someone else's cloud.
What one check returns
A call to POST /web/uptime takes a target URL and performs a reachability check right then: whether the endpoint responded, its status code, and how long it took to answer. Because the check runs at the moment you request it rather than on a fixed internal interval, you decide the cadence entirely — every thirty seconds during a deploy window, once an hour in steady state, or triggered on demand from an incident response script.
From wall-mounted pager alerts to programmable checks
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 check itself as a building block rather than a fixed product — something your own systems call the way they would call any other API, on the schedule your infrastructure actually needs rather than a vendor's default interval.
Built for scripts, not dashboards
Every request is asynchronous: you receive a task_id immediately, and the result is delivered afterward through a signed webhook — the practical option for feeding an alerting system or status page automatically — or a signed link valid for 24 hours for manual pulls. That design fits naturally into a status page generator, an incident response runbook, or a deploy pipeline that gates a rollback on a failed check.
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
Deploy-triggered health checks
Fire an uptime check immediately after a deployment finishes and gate a rollback decision on whether the endpoint responded correctly.
Custom-interval infrastructure monitoring
Build your own scheduler to check critical endpoints at whatever cadence matches their actual risk profile, from every few seconds to daily.
Status page backend
Power a public or internal status page by triggering checks on your own timer and publishing the status and latency you receive.
Incident response verification
Confirm an endpoint is reachable again as the final step of an incident runbook before closing out the alert.
FAQ
How is this different from a traditional always-on uptime monitor?
This uptime monitoring API runs a check only when you call it, so you control the schedule entirely from your own automation instead of relying on a vendor's fixed polling interval.
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 a single uptime check actually return?
It returns whether the target URL responded, its status code, and the response latency at the moment the check ran, delivered via webhook or a signed link.
How do I set up recurring uptime checks?
Trigger POST /web/uptime from your own cron, scheduler, or pipeline at whatever interval you need — the API performs each check on demand rather than maintaining its own polling schedule.
Can I get alerted immediately when a check fails?
Yes, configure a signed webhook and it delivers the result the instant the check completes, so your alerting system can react as soon as a failure is detected.
Can I monitor many endpoints in bulk?
Yes, each URL is its own independent asynchronous request, so checking a full list of endpoints is simply a matter of triggering monitor calls for each one from your own scheduler.
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
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, and soon from our app, email and Telegram.
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 '{"input":"…"}'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({
"input": "…"
})
});
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={
"input": "…"
},
)
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" => '{"input":"…"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"input":"…"}`)
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
{
"input": "…"
}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. |