Overview
OpenSRE’s Rocket.Chat integration delivers investigation findings to any channel your user or bot account can post to — useful for teams running self-hosted or cloud Rocket.Chat workspaces. Start the interactive shell withopensre (no subcommand). Slash commands below are run from that REPL.
Rocket.Chat support is outbound delivery only (investigation reports posted to a channel). Triggering investigations from Rocket.Chat chat is not supported yet. There is no gateway inbound /
messaging pair for Rocket.Chat.Prerequisites
- A Rocket.Chat workspace (self-hosted or cloud) and its base URL, e.g.
https://chat.example.com. - An account allowed to post in the destination channel. A dedicated bot account is recommended so findings are not attributed to a personal user.
- The Personal Access Tokens feature enabled on the server (
Admin → Settings → Accounts → Personal Access Tokens, on by default in most installs) — or admin access to create an incoming webhook.
Setup
Pick a mode
You can configure both — when both are present, delivery prefers the webhook. Incomplete token trio fails verify.
Option 1: Onboarding wizard (recommended)
/onboard. Choose Rocket.Chat, then pick token, webhook, or both. The wizard prompts for:
- Token mode: Server URL (
ROCKETCHAT_SERVER_URL), personal access token (ROCKETCHAT_AUTH_TOKENin.envand~/.opensre/credentials.json), user ID (ROCKETCHAT_USER_ID), and default channel (ROCKETCHAT_DEFAULT_CHANNEL) - Webhook mode: webhook URL — saved to the integration store (
~/.opensre/integrations.json) and/orROCKETCHAT_WEBHOOK_URLin.env; never written to the keyring (*_URLis non-keyring config). The URL often embeds a token — treat the whole URL like a password.
upsert_integration("rocketchat", ...).
Option 2: Environment variables
Credential resolution. Token mode: store →
resolve_env_credential("ROCKETCHAT_AUTH_TOKEN") (env then keyring). Webhook mode: store → plain ROCKETCHAT_WEBHOOK_URL env — never keyring. Server URL, user id, and default channel stay plain env / store.Credentials
Token mode: Create a Personal Access Token
- Sign in to Rocket.Chat with the account that should post findings.
- Open My Account → Personal Access Tokens (avatar menu → My Account).
- Enter a token name (e.g.
opensre) and select Add. Leave Ignore Two Factor Authentication checked unless your policy requires otherwise. - Rocket.Chat shows the token and your user ID once. Copy both — the token is your
auth_tokenand the ID is youruser_id. Treat the token like a password.
Token mode: Pick a destination channel
Findings are posted with the standardchat.postMessage REST endpoint:
Make sure the token’s account is a member of the channel (or has permission to post there).
Webhook mode: Create an incoming webhook
- As an admin, open Administration → Workspace → Integrations → New → Incoming.
- Enable the integration, set a name (e.g.
opensre), pick the destination channel, and choose the user the messages post as. - Select Save. Rocket.Chat shows the Webhook URL (
https://<server>/hooks/<id>/<token>). Copy it — treat the whole URL like a password.
Quick local test with Docker (token mode)
Requires--platform linux/amd64 on Apple Silicon (no arm64 image) and MongoDB 7.0, not 8.0 — 8.0 refuses to start under Docker Desktop’s Linux VM (“kernel versions 6.19 and newer has a known incompatibility”).
OVERWRITE_SETTING_Show_Setup_Wizard=completed and ADMIN_* variables skip the manual setup wizard. The 2FA override lets this disposable instance generate a PAT without a database change or restart.
-d "password=..."), and the token is captured into a variable rather than printed:
watchdog, not investigate, is deliberate here: Rocket.Chat has one registered tool, rocketchat_send_message, and it’s a delivery action (side_effect_level: EXTERNAL), not a read/investigation tool like the other integrations’ — there’s nothing for investigate to read from Rocket.Chat itself. Calling it mid-investigation would also need interactive approval, which doesn’t complete in one non-interactive demo run; watchdog triggers a real delivery autonomously by design.
Investigation tools
resolve_env_credential; webhook URL via plain env) — the agent never sees them. In token mode an explicit channel (or the configured default_channel) is targeted via chat.postMessage; in webhook-only mode messages go to the webhook’s fixed destination, and an explicit channel returns a configuration error instead of being silently ignored.
Delivery is an external side effect and requires approval. The result includes a stable status, sent, error_type, channel, and message_length shape so follow-up tool calls can tell configuration failures from Rocket.Chat delivery failures.
Background RCA completion notifications
default_channel; webhook-only setups deliver to the webhook’s fixed destination.
Confirm delivery with /background show <task_id>: the notify row reads rocketchat:sent, rocketchat:failed: <error>, or rocketchat:missing rocketchat integration: … when neither token credentials (with a default channel) nor a webhook is configured. A notification problem never fails the investigation itself.
See Background investigations.
Watchdog alarms
--chat-id overrides the configured default_channel (token mode) or is optional in webhook-only mode. Unlike scheduled deliveries (cron, Sentry digest), watchdog alarms accept either token credentials with a resolvable channel or a configured incoming webhook. Cooldown suppresses repeat alarms for the same threshold (--cooldown, default 5 minutes).
Hermes incident escalation
--cooldown-seconds). See Hermes.
Scheduled deliveries (cron)
--chat-id is the Rocket.Chat destination (#channel or @user). Scheduled deliveries always target that explicit destination, so they require token credentials — an incoming webhook’s destination is fixed at creation time and cannot honor --chat-id. See Cron.
Verify
/integrations verify rocketchat or /verify rocketchat.
With token credentials configured, this calls Rocket.Chat’s /api/v1/me endpoint and reports the authenticated @username. With webhook-only configuration, it runs a non-posting reachability probe against the webhook URL (a 404 means the URL or its embedded token is wrong; no message is delivered by the probe).
Delivery test:
Troubleshooting
/integrations verify rocketchat only calls /api/v1/me (or the webhook reachability probe), so it surfaces credential errors but cannot detect channel-routing problems. Delivery-time errors only show up when an investigation actually posts; they appear in OpenSRE logs as [rocketchat] post message failed: <error>.
Security
- Prefer a dedicated bot account and Personal Access Token for OpenSRE.
- Treat PAT and webhook URLs like passwords; webhook URLs are never stored in the keyring.
- Store secrets in the integration store / keyring / secret manager — not in source control.