Skip to main content

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 with opensre (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.
Interactive shell: /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_TOKEN in .env and ~/.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/or ROCKETCHAT_WEBHOOK_URL in .env; never written to the keyring (*_URL is non-keyring config). The URL often embeds a token — treat the whole URL like a password.
Credentials are also saved via 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

  1. Sign in to Rocket.Chat with the account that should post findings.
  2. Open My Account → Personal Access Tokens (avatar menu → My Account).
  3. Enter a token name (e.g. opensre) and select Add. Leave Ignore Two Factor Authentication checked unless your policy requires otherwise.
  4. Rocket.Chat shows the token and your user ID once. Copy both — the token is your auth_token and the ID is your user_id. Treat the token like a password.
If you missed the user ID, it is also shown when you regenerate the token, or under Admin → Users for admins.

Token mode: Pick a destination channel

Findings are posted with the standard chat.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

  1. As an admin, open Administration → Workspace → Integrations → New → Incoming.
  2. Enable the integration, set a name (e.g. opensre), pick the destination channel, and choose the user the messages post as.
  3. 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”).
The 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.
Log in and generate a PAT via the API. The password stays out of curl’s own argv (piped via stdin, not -d "password=..."), and the token is captured into a variable rather than printed:
Verify:
Send a real message through the supported watchdog delivery path (see Watchdog alarms below) rather than calling the tool class directly — this exercises the same threshold-detection, cooldown, and provider-routing code a production alarm uses: 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.
Check the channel — a real alarm message lands within a few seconds:
Teardown:

Investigation tools

The tool resolves credentials internally from the integration store, then the same env/keyring rules as setup (PAT via 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

On completion the summary — root cause, top analysis, next steps, and a short stats block — is posted as plain text, capped at 4,096 characters. Token mode posts to the configured 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

Same credential rule as watchdog alarms, and the same per-incident-fingerprint cooldown (--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

Interactive shell: /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:
Findings should appear in the configured channel as a message with an attachment titled Investigation Complete. Long reports are truncated to 4,096 characters.

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.