ForHosting KIT · Web Scraping & Monitoring

Multi-region uptime

One region seeing a timeout doesn't mean your site is down — it might mean that one network path is having a bad day. This endpoint checks your URL from several vantage points at once and returns a per-region verdict, so you can tell a real outage from a local routing hiccup before you page anyone.

● StablePer request + per check$0.002
Use it from WebAPIEmailApp soonTelegram soon

Why a single ping is a bad witness

A classic uptime check hits your server from one location and treats the answer as gospel. But the internet is a mesh of independent paths, and a single upstream provider having a rough afternoon can make a perfectly healthy server look dead from that one vantage point. Anyone who has chased a false-positive outage at 3 a.m. knows the cost of trusting one witness. web.uptime_multi exists so the verdict comes from a quorum, not a single opinion.

What you send, what comes back

POST /web/uptime-multi with the target URL and any check options (method, expected status, timeout). The task runs asynchronously: you get a task_id immediately, and the checks fire out from several regions in parallel. The result payload lists each region's response code, latency and reachability, plus a consolidated status so you don't have to write your own quorum logic every time.

Who actually needs this

Teams running their own status pages, agencies watching dozens of client sites, and SaaS platforms that bake uptime data into a customer dashboard all hit the same wall with single-region checks: alert fatigue from false positives. Multi-region checking is the standard fix used by serious monitoring providers, and now it's available as a plain API call instead of a whole platform you have to adopt.

Built for pipelines, not dashboards

Because it's async with webhook delivery, this fits naturally into a cron job, a status-page generator, or an incident-response bot — no polling required. Fire the check, let the webhook land in your alerting system, and decide your own threshold for what counts as 'down' (all regions failing, majority, or any single one, depending on how paranoid you want to be).

Pricing that matches the workload

At $0.002 per request you can check a handful of endpoints every minute all day without doing mental math about your bill. Failed tasks — meaning our task failed to execute, not that your site was down — are retried automatically up to three times and are never charged, so a transient hiccup on our side never costs you a cent.

Public status page backend

Feed a customer-facing status page with real multi-region data instead of a single self-reported ping.

Agency client watch

An agency managing 40 client sites schedules a check every five minutes per domain and routes webhook alerts into its ticketing system.

Pre-deploy sanity check

A CI pipeline calls the endpoint right after a deploy to confirm the new release is reachable from every region before marking the rollout successful.

Regional outage diagnosis

When one customer reports 'your site is down' and others don't, the per-region breakdown quickly shows whether it's a local ISP issue or a real outage.

How many regions does each check cover?

The response includes results from multiple independent regions per request, giving you a quorum-based view instead of a single data point.

Is there a free tier for this uptime API?

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.

How do I get the results?

Via a signed webhook to your endpoint (recommended for automation) or a signed link valid for 24 hours if you'd rather poll.

What counts as 'down' in the response?

We give you the raw per-region status codes and latencies; you decide your own threshold (any region down, majority down, or all down) since that depends on your tolerance.

Can I check non-HTTP ports?

This endpoint focuses on HTTP/HTTPS reachability with configurable method and expected status; it is not a raw TCP/ping scanner.

Am I charged if a check fails?

Only if your target is genuinely unreachable — that's a valid result, not a failure. If our task itself fails to run, it retries automatically up to three times and is never billed.

Can I run this every minute for many domains?

Yes, that's exactly the intended use; at $0.002 per request it's built for high-frequency, multi-domain monitoring.

How is this different from a simple uptime cron script?

A single-server script only sees the internet from where it runs; this endpoint checks from several regions per call and returns a consolidated verdict without you maintaining the infrastructure.

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.

POSThttps://api.kit.forhosting.com/web/uptime-multi

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.

curl -X POST https://api.kit.forhosting.com/web/uptime-multi \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"input":"…"}'
{
  "input": "…"
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "web.uptime_multi",
  "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.

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

timeout_sec30
max_crawl_pages25
HTTPCodeMeaning
401unauthorizedMissing or invalid API key.
402insufficient_balanceYour balance doesn't cover the task price.
404unknown_typeThat task type doesn't exist.
429rate_limitedToo many requests. Use the webhook instead of polling.

Read the full KIT documentation →