How it works

From DNS record to first bark.

The homepage gives you the three steps. This is the whole pipeline: how domain verification works, what a monitor actually does, when an incident opens and closes, and where the alerts end up.

01 - Verification

Prove the domain is yours.

Before Barkme watches anything, you verify the domain with a single DNS TXT record. In your DNS provider, add a record on the apex with host @ and the value barkme-verify= followed by the token we show you. That's it - it usually takes about 2 minutes.

  • One record per domain, added once. Verifying the apex covers every subdomain and every URL beneath it.
  • You can only monitor domains you own or operate - verification is what enforces that.
  • Propagation usually takes a couple of minutes. We re-check automatically until the record shows up.
Example - DNS TXT record
Type Host Value
TXT @ barkme-verify=9f3a71c2d84b
acme.com Verified

Once verified, acme.com unlocks monitors for every URL under it - api.acme.com, shop.acme.com/checkout, anything.

02 - Monitors

Point a watchdog at a URL.

A monitor is a URL plus a schedule. Barkme sends an HTTP GET from the outside - like your users - on the interval you pick: every 30 seconds, every minute, every 2 minutes, or every 5. A 2xx response counts as up. Everything else counts as down: a 3xx redirect, a 4xx or 5xx, a timeout, or a DNS or TLS failure.

Each monitor has its own timeout, from 1 to 120 seconds, and its own set of notification channels. Group monitors into projects by client, product, or team - each project can get its own status page later.

The Free plan checks every 5 minutes, Founder unlocks 1-minute checks, and Pro unlocks all four intervals including 30 seconds.

Example - Monitor config
URL https://shop.acme.com/checkout
Interval
30s 1m 2m 5m
Timeout 10s
Channels
Email Slack Linear

03 - Incidents

Confirm first. Then bark.

A single blip will not wake you. When a check fails, it is retried two seconds later - and it takes two consecutive failed checks before an incident opens. Four failed requests in total. So a 30-second monitor alerts in about a minute, and a 5-minute monitor takes five to ten.

The incident is backdated to the first failed check, so the confirmation window still counts against your uptime. A monitor only ever has one open incident at a time - a long outage stays one incident, not a stream of alerts.

We are slow to open and quick to close: the incident resolves on the first successful check, and you get a recovery notice with the total downtime. Every incident is logged with its status code and duration.

Example - Incident record
Monitor name Response status Opened at Downtime duration State
Checkout 503 Service Unavailable 2026-08-01 12:41:35 Ongoing Open
Checkout 503 Service Unavailable 2026-08-01 12:41:35 4m 9s Resolved

Same incident, two moments - the row you'd see on the Incidents page the instant it opens, and again once it resolves.

04 - Expiry tracking

Outages you can see coming.

An expired SSL certificate or a lapsed domain registration takes a site down just as hard as a crashed server - and both are entirely predictable. Barkme checks every verified domain once a day and warns you 30, 14, 7, and 1 day before either date.

Each threshold fires once, so you are not nagged daily, and you can toggle certificate and registration alerts separately per domain. Expiry alerts go to your email, Slack, Telegram and webhook channels - Linear and Trello only handle incidents.

T-30 T-14 T-7 T-1
Example - Expiry tracking
acme.com Verified
SSL certificate 64d left · 2026-10-05
Domain registration 172d left · 2027-01-20

Expiry notifications fire 30/14/7/1 days before the date through your alert channels.

05 - Status pages

Show clients you're up.

Every project can publish a live status page: 90 days of uptime per monitor, refreshed about every minute. On the Free plan it lives on a barkme.dev subdomain - acme.barkme.dev. Paid plans can serve it from your own domain, like status.acme.com.

A custom domain takes two DNS records: a TXT record to prove ownership and a CNAME pointing at cname.barkme.dev. Add both, click Verify DNS, and the page is served from your domain - HTTPS included.

Status pages are built for sharing: monitor URLs are never shown, you can rename each monitor for the public view, and the page is marked noindex so it stays out of search results.

Example - Public status page Published
Acme status status.acme.com
Website Operational
API Operational
Checkout Operational
Example - Custom domain DNS
Type Host Value
TXT status.acme.com barkme-verify=4c1e88ab
CNAME status.acme.com cname.barkme.dev

06 - Channels

Barked where your team already is.

Alerts travel through the channels you connect. Every channel is verified with a real test alert before anything fires, and you can mute one any time without deleting it. Email and Telegram are personal; Slack, Linear, Trello and webhooks are shared - one destination for the whole team, set up by an owner or admin.

Email

Personal

Transactional delivery, every time. Free includes one address, Founder five, Pro has no limit.

Slack

Shared

Incidents and recoveries posted to the channel your team picks. One Slack channel per team, set up by an owner or admin.

Telegram

Personal

Connect the Barkme bot and get barked in a private chat. Not on Free - Founder includes five, Pro has no limit.

Custom webhook

Shared

Every incident and expiry alert POSTed to your HTTPS endpoint as JSON, signed with an X-Barkme-Signature header - an HMAC-SHA256 of the timestamp and raw body you can recompute to verify us.

Linear

Shared

An incident opens a Linear issue automatically - and closes it when the site recovers. Nothing to triage after the fact.

Trello

Shared

Same auto-open, auto-close flow with a Trello card, for teams that live on boards.

That's the whole pipeline

Ready to put a watchdog on it?

Verify a domain, add a monitor, connect a channel - about 5 minutes end to end.