How to Build an On-Call Engineer Knowledge Lookup in Slack

Let an on-call engineer post a symptom into a Slack incident channel, have Spojit search your runbook collection, and reply in-thread with the most relevant remediation steps.

What This Integration Does

When an incident fires at 3am, the slowest part is often finding the right runbook. This workflow turns your Slack incident channel into a self-service lookup desk: an engineer asks "Redis connection pool exhausted, what do I do?" in the channel, and seconds later Spojit replies in the same thread with the matching remediation steps pulled straight from your runbooks. The engineer never leaves Slack, never digs through a wiki, and gets an answer grounded in your own documentation rather than a generic guess.

The workflow is started by a Webhook trigger that a Slack slash command or event subscription posts to. The incoming text is used as a Query against a persistent Knowledge collection that holds your embedded runbooks, and Miraxa, the intelligent layer across your automation, synthesizes the top matches into a concise answer. A Connector node then calls the Slack send-message tool to post that answer back into the originating channel, threaded under the question. The workflow holds no state between runs: every call is independent, so re-runs simply re-query the collection and post again. The runbook collection itself is long-lived and is maintained separately from this lookup workflow.

Prerequisites

A Slack connection added under Connections with permission to post messages (used by the send-message tool).
A persistent Knowledge collection (for example runbooks) already created and populated with your runbook documents. See the related articles below for building one.
A Slack app configured to send a slash command or event payload to a Spojit webhook URL. The payload must include the engineer's question text and the channel ID.
A signing connection for verifying the inbound webhook. Slack is one of the supported HMAC schemes.
The same embedding model that was used when the runbook collection was created, so queries match the embedded chunks.

Step 1: Add a Webhook trigger to receive the question

Create a new workflow and set the Trigger type to Webhook. Copy the generated URL and configure your Slack app (slash command or event subscription) to POST to it. Under Signing connection, pick the Slack scheme so Spojit verifies the request signature and rejects forged calls. The trigger output is the parsed JSON body, available as {{ trigger }}. A typical Slack slash command body exposes the fields you need:

{
  "text": "redis connection pool exhausted on checkout-api",
  "channel_id": "C0123ABCD",
  "user_name": "amara",
  "response_url": "https://hooks.slack.com/commands/..."
}

You will reference the question as {{ trigger.text }} and the channel as {{ trigger.channel_id }} downstream.

Step 2: Acknowledge the request quickly

Slack expects a fast acknowledgement. Add a Response node right after the trigger and return a short placeholder so the engineer sees immediate feedback while the lookup runs:

{
  "response_type": "ephemeral",
  "text": "Searching the runbooks, one moment..."
}

The rest of the workflow continues after the response is sent, so the final answer arrives as a follow-up message rather than blocking the acknowledgement.

Step 3: Query the runbook collection with a Knowledge node

Add a Knowledge node and set its mode to Query. In Collection, pick your persistent runbooks collection (not Transient, since the documents already live there). Set the Prompt to the engineer's question and frame it so the answer is actionable:

An on-call engineer reported: "{{ trigger.text }}".
Return the most relevant remediation steps from the runbooks as a short,
numbered checklist. If no runbook clearly matches, say so plainly.

Set Result Count to 5 (the default) so the lookup considers the five closest runbook chunks, choose a Model for synthesis, and name the Output Variable lookup. To get a clean structure you can post directly, supply a Response Schema so the node returns predictable fields:

{
  "type": "object",
  "properties": {
    "answer": { "type": "string" },
    "runbook": { "type": "string" },
    "matched": { "type": "boolean" }
  },
  "required": ["answer", "matched"]
}

The result is then available as {{ lookup.answer }}, {{ lookup.runbook }}, and {{ lookup.matched }}.

Step 4: Branch on whether a runbook matched

Add a Condition node that checks {{ lookup.matched }} is true. The true branch posts the remediation steps; the false branch posts a graceful "no matching runbook found" message so the engineer is never left waiting on silence. Keeping the two paths separate also lets you word the no-match reply to nudge the engineer toward escalation or paging the relevant team.

Step 5: Post the answer back to the channel with Slack send-message

On the true branch, add a Connector node in Direct mode, choose your Slack connection, and select the send-message tool. Map the inputs:

channel: {{ trigger.channel_id }} so the reply lands in the incident channel it came from.
text: the formatted answer, for example:

:books: *Runbook match: {{ lookup.runbook }}*

{{ lookup.answer }}

_Asked by {{ trigger.user_name }} - verify before acting in production._

To keep the channel tidy, thread the reply under the original message when your Slack payload carries the message timestamp: set the optional thread_ts input to that value. Direct mode is the right choice here because you are making one predictable call to one tool with no AI cost. On the false branch, add a second Connector node with the same send-message tool but a short text such as No runbook matched "{{ trigger.text }}". Consider paging the platform on-call.

Step 6: Notify a fallback channel if the post fails

Add a final safety net so a failed Slack post never disappears silently. After the Connector node, use a Send Email node configured to email the on-call lead. Set Recipients to your team distribution address, a Subject like Runbook lookup could not post to Slack, and a Body that includes {{ trigger.text }} and {{ lookup.answer }} so the answer is preserved even if delivery to the channel fails. Set If sending fails to Continue anyway so this fallback never halts the run.

Tips

Keep runbooks small and single-topic when you embed them. Tight, focused documents produce sharper matches than one giant operations manual, because each chunk is more semantically distinct.
Use the same embedding model for the lookup that you used to build the runbooks collection. Mismatched models degrade relevance badly.
Word the Prompt to demand a numbered checklist. On-call engineers act faster on ordered steps than on prose.
If you want richer reasoning across multiple runbooks, you can switch the lookup posting node to Agent mode, but Direct mode with the send-message tool is cheaper and fully deterministic for a single post.

Common Pitfalls

Forgetting the signing connection on the webhook. Without HMAC verification anyone who learns the URL can trigger lookups. Always pick the Slack scheme.
Passing a channel name instead of an ID. The send-message tool's channel input expects a channel ID such as C0123ABCD, not #incidents.
Querying a Transient collection by mistake. Transient collections only hold documents embedded earlier in the same run, so a lookup against one returns nothing. Your runbooks must live in a persistent collection.
Skipping the early Response node. Slack slash commands time out quickly, so acknowledge first and deliver the answer as a follow-up message.

Testing

Before wiring this to a live incident channel, post a question to a private test channel. Send a known symptom that you are certain has a runbook (for example a database failover) and confirm Spojit replies in-thread with the right steps. Then send a deliberately unmatched phrase to verify the Condition false branch posts the graceful no-match message. Check the execution history for each run to see the {{ lookup }} output and confirm the matched runbook name is correct, then point your production Slack app at the webhook URL once you are satisfied.