Ops Bot

The Ops Bot (@proximaopsbot) is the operations-facing Telegram bot. Unlike the Service Desk Bot (which is per-user and ticket-focused), the Ops bot is group-based: you add it to a Telegram group, bind that group to a Console client or team, and the group then becomes a live operations surface — alerts, Jira ticket activity, and an on-demand AI Investigator, all scoped to the bound client.

It authenticates to the Console backend with a service-account API key and acts on the same RBAC seam the web UI uses: every action a person takes (Acknowledge, Resolve, ask the AI) is attributed to their linked Console account and gated by their permissions.

Identity during migration

The Ops bot is being consolidated onto @proximaopsbot (the bot already present in the client/team groups). Its routing config is moving off the legacy n8n bot onto Console — see the Overview engineering note.

What it does

1. L1 alerts (page + act)

When an infra alert fires, Console's escalation engine pages the groups bound to that client. The message depends on the group's audience:

• Internal (responder) groups get the full alert detail plus Acknowledge and Resolve buttons.
• Client groups get a severity-gated, status-only message — no internal detail, no action buttons.

Tapping Acknowledge / Resolve applies the action in Console, attributed to your linked user and checked against your per-client alerts:write permission. A client-facing status message is then edited in place as the incident progresses.

2. Jira ticket activity

The Ops bot delivers Jira ticket activity — new tickets, comments, and status changes — to the right groups: the responsible team group and the client group. Which group receives what is driven entirely by the /bind config (client ↔ project labels ↔ group, team ↔ group), so onboarding a new client/team is just a /bind in their group.

3. Reactive AI Investigator

@mention the bot — or reply to one of its messages — in a bound group, e.g.:

@proximaopsbot is web-prod-01 healthy right now?

…and it runs a single read-only AI Investigator turn scoped to that group's client, then posts a 🤖 answer. It is read-only (no write tools), tenant-scoped to the group's bound client, gated by the client's l1_agent feature flag, and secret-sanitized. A per-group kill-switch can disable reactive replies.

Audiences: internal vs client

Every group is bound at one audience, which decides what it receives:

--audience	The group is…	Receives
internal	a ProximaOps responder group	full alert detail + Acknowledge/Resolve buttons
client	a customer-facing group	severity-gated, status-only (no buttons, no internal detail)

internal is the safe default. Promoting an existing client group to internal requires super-admin — it would start pushing that chat full detail + action buttons, a privilege escalation of the chat itself.

Commands

Run these inside the group you want to configure (the bot is group-only for binds).

Command	What it does
/link <code>	Links your Telegram account to your Console user (generate the code in the Console profile). Required before you can bind or act on alerts.
/bind <client-slug> --audience internal|client [--team <name>]	Binds this group to a client at the given audience. Captures the forum topic it was run in.
/bind --team <team-name> [--mention <@handle>]	Binds this group to a cross-client team (no client). --mention sets the team-lead handle pinged on status notifications.
(inline buttons)	Acknowledge / Resolve on alert cards.
(@mention / reply)	Triggers the reactive AI Investigator.

How to onboard a group

1. Add @proximaopsbot to the Telegram group (and, if the group uses topics, run the next step inside the topic you want notifications to land in).
2. Make sure your Telegram account is linked: /link <code> (generate the code in the Console profile → Telegram).
3. Bind the group:
   • Client's status group → /bind it-unisoft --audience client
   • ProximaOps responder group → /bind it-unisoft --audience internal
   • Cross-client team group → /bind --team "Infra Team" --mention @lead
4. Done — the group now receives the matching alerts and Jira activity, and you can ask the AI by @mentioning the bot.

Authorization

Defense-in-depth (all enforced server-side, never trusting the bot's request body):

• Service-account pin — the endpoints accept only the pinned Ops-bot service account.
• Linked user — the acting human is resolved from your Telegram link; unlinked users are rejected.
• Client bind (/bind) — requires telegram_ops:write and that your linked account has access to the target client. Re-pointing a chat to a different client, or promoting client→internal, requires elevated access (super-admin / access to the current owner).
• Team bind (/bind --team) — a team group has no client tenant boundary, so it requires the global telegram_ops:write permission (super-admins hold it implicitly).
• Alerts / AI — Acknowledge/Resolve require per-client alerts:write; the AI Investigator is gated by the client's l1_agent flag and is read-only.

Deployment & identity

The Ops bot is a Go service (telegram/opsbot/) deployed to Kubernetes (console-system), long-polling Telegram and calling Console over CONSOLE_API_URL with CONSOLE_API_KEY. Its bot token is OPS_TELEGRAM_BOT_TOKEN; the backend sends as PROXIMA_OPS_TELEGRAM_BOT_TOKEN. See Deployment.