Wake the right person.
TokayOps sits between Alertmanager and the engineer who has to fix it. It turns each Alertmanager group into one live escalation, works out who is on call at this instant, escalates until somebody answers, and closes the loop in Slack or Telegram.
One container your Postgres source-available
Wake somebody once, not on every repeat.
Grouping is Alertmanager's job, and it stays there. The first delivery opens one Alert Group and starts one escalation. Every repeat afterwards merges into it: alerts added, cleared, or re-fired land on the same timeline, the chat message is edited in place, and nobody is woken a second time for the same thing.
Find who is on call now.
The alert's team label picks the team, its severity picks the
escalation policy, and anything unlabelled lands in triage rather than nowhere.
The schedule answers who is on call at this instant - after the rotation was edited, after
somebody swapped a weekend, across the night the clocks change - and that answer
sticks: editing the rotation cannot redirect a page already in flight.
Page until somebody answers.
Every member of the on-call group is messaged at the same moment, with the team channel alongside, and one failed message does not hold up the rest. Steps carry their own delays and timeouts, and nothing is dropped if a server dies mid-escalation - the step is picked up again rather than lost.
- slack live
- telegram live
- sms planned
- phone call planned
Take ownership without leaving the chat.
Buttons in Slack, buttons in Telegram. Ack claims the group and stops the escalation at the same moment, so the next step cannot fire after somebody has answered. Resolve closes it. The message is edited in place, so the channel never fills up with copies of itself.
- new
- processing
- triggered
- acknowledged
- resolved
- closed
Runs on your machines.
The last alert cleared and the group closed itself. Point TokayOps at a Postgres and the whole control plane runs on machines you own - every alert group, timeline and schedule lives in your database. What leaves is the notification itself, to the chat provider you chose.
curl -fLO https://raw.githubusercontent.com/tokayops/tokayops/main/docker-compose.prod.yml
curl -fL -o .env https://raw.githubusercontent.com/tokayops/tokayops/main/.env.example
# In .env: generate ENCRYPTION_KEY, JWT_SECRET and DB_PASSWORD, set
# APP_ENV=production and TOKAY_SELF_URL. Then keep the file - the keys
# have to be the same on every start.
docker compose -f docker-compose.prod.yml up -d
That pulls :latest, the newest stable release.
What a version number promises.
- start Postgres and one Go binary come up together. Health lands on :9090, the UI on :8080.
- create the first admin One CLI call inside the container. The first account on an empty database becomes admin.
- connect a channel Add a Slack or Telegram integration, then point the Alertmanager webhook at TokayOps.
- one container
- A single Go binary. No agent, no sidecar, no message broker to operate.
- your postgres
- The schema lives in a database you already back up. Your system of record stays in your Postgres; notification payloads are sent only to the providers you configure.
- no per-seat bill
- Add the whole team. Nothing about the price changes.
- FSL-1.1-Apache-2.0
- Source available today; every release converts to Apache-2.0 two years after it ships.
- tagged releases
- Semantic versions on GHCR, 0.1.0 being the current one. :latest follows them; TOKAY_TAG or a digest pins one.