Send outage alerts to the tools your team already uses.

Many teams do have monitoring, but the alerts go to an email inbox nobody watches. Barkme sends alerts to the places your team already looks.

Who this is for

Teams of five to fifteen people, with no dedicated SRE and no formal on-call. Everyone ships, and everyone is a little responsible for production. In practice that means nobody is. An alert that lands in one person's inbox, or in a shared mailbox, gets read when someone has time. An alert that lands in the team's Slack channel and opens a ticket in the tracker the team already works from gets picked up.

Where alerts can go

Barkme can send alerts to email, Slack, Telegram, Linear, Trello and a webhook. Each channel sends a test alert when you connect it, so you know it works before a real outage.

Email and Telegram are personal: each person connects their own and only they receive it. Slack, Linear, Trello and the webhook are shared. Each team has one of each, and only an owner or admin can set them up. You can mute any channel without deleting it, which helps during a planned migration.

Setting it up for a team

1. Verify your domains. One TXT record on each apex, with host @ and the barkme-verify= token from your dashboard. It usually takes about two minutes, and one verified apex covers app., api., docs. and every other subdomain.
2. Add a monitor for each thing customers depend on. The web app, the API, the marketing site, the docs. For the API, a health check endpoint that tests the database and the queue tells you more than a plain homepage check. Set each monitor's interval (every 30 seconds on Founder and Pro) and its timeout, from 1 to 120 seconds.
3. Invite the team. An owner has full control and is the only one who manages billing. An admin can invite people and set up shared channels. A member uses the dashboard without managing the team. Invitations expire after one day.
4. Connect the shared channels. An owner or admin connects Slack to the channel the team watches, then Linear or Trello, then the webhook if you have internal tools that should hear about incidents.

Tickets are created for you

On Pro, each incident creates a Linear issue or a Trello card. When the monitor recovers, Barkme adds the total downtime to the same ticket. It does not close the ticket, because someone still needs to find out why it broke. There is more on this setup in incidents to Linear and Trello.

What an incident looks like

At 14:00 a deploy goes out with a bad migration, and the API starts returning 500s.

The API monitor checks every 30 seconds. The first check fails, Barkme retries two seconds later, and that fails too. The next check fails again, so an incident opens, dated back to 14:00. In Slack, a message headed with "DOWN" and the monitor name shows the URL, the time it was detected, the error and the phase it failed at. Here that is the response, so the DNS, the connection and the certificate were fine and the problem is in the app. At the same moment a Linear issue appears with the same details.

Someone replies in the Slack thread that they are on it and rolls back the deploy. At 14:12 the next check passes. The incident resolves on that first good check, Slack gets an "UP" message, and the Linear issue gets a comment with the resolve time and the total downtime. The issue stays open on purpose. Whoever picks it up next has the start time, the end time and the error in one place.

A monitor only has one open incident at a time, so a long outage gives you one ticket. It won't fill the backlog with duplicates.

Send events to your own tools

The webhook sends each event as JSON, signed with HMAC-SHA256 in the X-Barkme-Signature header, so your systems can check the request came from Barkme.

The digest covers the timestamp and the raw body, using a signing secret shown on the channel. Recompute it on your side and compare before you trust the request. Incidents arrive as incident.opened and incident.resolved. Domain expiry warnings and reputation alerts come through the same webhook, so one endpoint can feed an internal dashboard, a chat bot or an incident log.

Fewer false alarms

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. On Pro, checks run every 30 seconds, and monitors and seats are unlimited.

If your API sits behind a WAF or a rate limiter, it may block the checker and cause a down alert while customers are fine. The alert names the probable cause when the error looks like this. Whitelist the Barkme prober IP, shown under Settings then Team, and raise the monitor's retries before alert if bans are short. Uptime monitoring false alarms covers the common causes.

What Barkme does not check

Barkme only checks over HTTP(S). It does not do ICMP, TCP port or heartbeat checks.

It also has no on-call rotations, escalation policies, phone calls or SMS. Alerts go to the channels above. If your team needs paging with escalation, that is a job for a separate tool. How Barkme compares to Better Stack sets out the differences.

Which plan fits

Free has one seat and email only, so it is for trying Barkme before you bring the team in. Founder, at $19 a month, covers five seats, 30 monitors across five domains, 30-second checks, and Slack and Telegram. That is enough for a small team that lives in Slack. Pro, at $39 a month, is the plan built for this page: unlimited monitors and seats, 50 domains, and Linear, Trello and the signed webhook. Both paid plans include status pages on your own domain, so customers can check the API themselves. The pricing page has the full comparison.