Check that your API responds, the same way your customers call it.

Your website can load fine while your API is broken. Often nobody notices until a customer or partner complains. Barkme checks the API directly.

Why the website check is not enough

Most teams start by monitoring the homepage. That tells you the web server answers. It does not tell you that the API behind your app, your mobile client or your partner integration still works.

The two often run on different hosts, deploy on different schedules and fail for different reasons. A bad migration, an expired database password or a crashed worker can leave the marketing site serving cached pages while every API call returns a 500. The homepage monitor stays green the whole time.

If customers or partners call your API, it needs its own monitor, pointed at the API itself.

How a check works

A monitor sends an HTTP(S) GET request to a URL from outside your servers, like a client would. A 2xx or 3xx response, after any redirects, counts as up. Anything else, including a timeout or an SSL error, counts as down. You can set the timeout and the Accept header.

The Accept header can be application/json, text/html, text/plain or */*, and you can add a Content-Type header if your framework needs one to route the request. The timeout is set per monitor, anywhere from 1 to 120 seconds. If your endpoint usually answers in 200 ms, a tight timeout catches a slow API as well as a dead one.

Every check sends the same Barkme User-Agent, so the request is easy to spot in your logs and easy to allow through a firewall or bot filter.

It works best with a health endpoint that checks what your API depends on. See our guide on what a /health endpoint should check.

Setting it up

1. Verify the domain. Add one TXT record on the apex of the API's domain, with host @ and the value Barkme shows you. It usually takes about two minutes. Verifying the apex covers every subdomain, so api.example.com and status.example.com are both covered once example.com is verified.
2. Add a monitor. Give it a name, paste the endpoint URL, pick the interval, the timeout and the Accept header. The monitor belongs to a project, which keeps an API's monitors together.
3. Connect a channel. Email works on every plan. Slack and Telegram are on Founder and Pro, and Linear, Trello and a signed webhook are on Pro. Every channel sends a test alert when you connect it, so you know it works before anything breaks.

That's it. The first check runs on the interval you picked.

Checked twice before an alert

Barkme checks again before alerting, and by default opens an incident only after two failed checks in a row. The incident starts from the first failure and closes on the first success.

Inside each check, a failed request is retried after two seconds. So it takes four failed requests in total before you hear anything, and a single dropped connection does not page anyone. If your API sits behind a rate limiter that sometimes blocks the prober for a few seconds, you can raise "Retries before alert" on that monitor so a short ban expires before Barkme alerts.

Read more about why uptime monitors send false alarms and how to stop them.

What an alert looks like

Say a deploy at 11:20 breaks the orders API and it starts answering with a 503. The first check fails, the retry fails, and the next check a minute later fails too. An incident opens, backdated to 11:20, and an alert goes to every channel you have connected:

DOWN - Orders API
Monitor : Orders API
URL     : https://api.example.com/health
Endpoint: api.example.com
Detected: 2026-10-14 11:20 (UTC)

When the request fails before a response comes back, the alert also names the error and the stage it failed at: DNS lookup, connection, TLS handshake or response. If the error matches a known pattern, such as a firewall dropping the prober, the alert names the probable cause too.

A monitor only has one open incident at a time, so a long outage sends a single alert. When the deploy is rolled back and the next check passes, the incident closes and a recovery notice goes out with the total downtime. All times are in your team's timezone.

How often

Choose every 30 seconds, 1, 2 or 5 minutes for each monitor. The Free plan goes down to every minute. Founder and Pro go down to 30 seconds.

With a 30-second interval, an outage is confirmed in about a minute. With 5 minutes, it takes five to ten. Our post on choosing a monitoring interval goes through the trade-off.

What Barkme does not check

Checks are HTTP(S) only. There are no ICMP, TCP port or heartbeat checks, and you can only monitor hosts on a domain you have verified.

Every check is a GET. Barkme does not send a request body, does not add your auth token, and does not read the response body. It looks at the status code. If an endpoint needs a token, put a public health endpoint next to it that returns a 5xx when something it depends on is down.

Which plan fits

If you run one API and want to know when it goes down, the Free plan is enough to start: three monitors on one domain, checked every minute, with email alerts.

Founder ($19/mo) suits a small product with a few services. You get 30 monitors on five domains, 30-second checks, and alerts in Slack or Telegram. Pro ($39/mo) removes the monitor cap and adds Linear, Trello and the signed webhook, so every API incident can become a ticket or feed your own tooling. The pricing page has the full comparison.