Tutorial: Webhook Alert Auto-Processing

Using “Webhook alert auto-processing” as the example, this tutorial shows how the Webhook Callback trigger, Conditional Branch severity routing, Knowledge Base retrieval, and Lansenger MCP notifications combine in a LanSphere Workflow. Unlike scheduled triggers, a Webhook is called actively by an external system — ideal for event-driven real-time response. It is for ops and developers who need to connect monitoring systems and automate alert distribution and handling.

Scenario and Value

Monitoring-system alerts handled by humans watching a screen have plenty of issues:

• Alerts fire around the clock — easy to miss during nights and holidays with no one on duty;
• Different severity levels are jumbled together, and on-call staff cannot tell what is urgent;
• When an alert arrives, staff don’t know how to handle it — digging through docs wastes time;
• P0 critical alerts need to notify both the on-call person and the emergency group simultaneously — manual operation delays response.

Automate the alert-handling chain with a Workflow: an external monitoring system triggers via Webhook Callback → Conditional Branch routes by severity → Knowledge Base retrieves handling plans → LLM generates a summary → Lansenger MCP notifies the corresponding people and groups. The result is second-level response with tiered delivery.

What You Will Build

An “Alert Auto-Processing” Workflow app: triggered by an external monitoring system via Webhook Callback, it receives alert JSON data (severity level, system name, alert content, timestamp). A Conditional Branch node splits it into three paths by severity — P0 Critical, P1 Important, and P2 General. P0 retrieves from the Knowledge Base, the LLM generates a summary, and Lansenger MCP sends a private message to the on-call person plus a group message to the emergency group. P1 retrieves from the Knowledge Base, the LLM generates a summary, and a group message goes to the ops group. P2 has the LLM generate a brief summary recorded to the output.

Chain: Webhook Callback → Conditional Branch → [P0 → Knowledge Base → LLM → MCP (private message to on-call) + MCP (group message to emergency group)] / [P1 → Knowledge Base → LLM → MCP (group message to ops group)] / [P2 → LLM → Output] → Output.

Recommended Flow

Preparation

Step 1: Create the App and Configure the Webhook Trigger

1. Click “New Project,” pick the app type “Workflow,” and fill in the name (e.g., “Alert Auto-Processing”).
2. In the canvas, select “Webhook Callback” as the Start node (replacing the default “Input” node). Once added, the platform generates a callback URL — external systems trigger the Workflow by sending a POST request to that URL.
3. The Webhook Callback node receives the request body sent by the external system and exposes it as an output variable for downstream nodes to reference. Monitoring systems typically send alert data in JSON. Sample fields:

{
  "level": "P0",
  "system": "Order Service",
  "content": "Database connection count exceeds threshold, currently 980/1000",
  "timestamp": "2026-08-04T02:30:00Z"
}

4. Add Environment Variables for the on-call staff and group IDs (e.g., DUTY_STAFF_ID, EMERGENCY_GROUP_ID, OPS_GROUP_ID) with the corresponding Lansenger IDs — mark them as secret variables.

Note: The callback URL is the sole entry point for triggering the Workflow — it can only be called by external systems after saving and publishing. During debugging, use the simulated-request feature provided on the page.

Step 2: Orchestrate the Conditional Branch

1. Add a “Conditional Branch” node, connected after the “Webhook Callback” node.
2. Configure three branches, judging by the level field in the alert JSON:

3. Configure a fallback branch — unknown levels go to the P2 path (generate a summary, then record to output).

Tip: The Conditional Branch conditions reference the level field in the Webhook Callback node’s output variable. Make sure the field name matches the JSON sent by the monitoring system.

Step 3: Connect Knowledge Base and LLM on the P0 and P1 Branches

The P0 and P1 branches share a similar chain structure. Using P0 as an example:

1. Add a “Knowledge Base” node, associate the ops Knowledge Base, set the input to reference the alert content field (the Webhook output variable), set Top K to 3, and set retrieval mode to hybrid retrieval.
2. Add an “LLM” node, connected after the Knowledge Base. Reference the alert data and Knowledge Base recall snippets as context. Sample prompt:

You are an ops alert assistant. Below are the alert information from the monitoring system and the handling plans retrieved from the Knowledge Base:

Alert level: (insert level variable here)
Alert system: (insert system variable here)
Alert content: (insert content variable here)
Alert time: (insert timestamp variable here)
Retrieval results: (insert Knowledge Base node's output variable here)

Generate an alert summary and handling suggestions with these requirements:
1. Open by marking the alert level and system name; summarize the alert content in one sentence.
2. Provide handling suggestions based on the retrieval results, in bullet points.
3. When the retrieval results contain no matching plan, reply: "No standard handling plan found; on-call staff to investigate."
4. Keep it within 200 characters, suitable for quick reading in a group chat.

3. The P1 branch follows the same pattern — connect the Knowledge Base and LLM with an identical prompt structure.

Step 4: MCP Nodes Notify On-Call Staff and Groups

P0 Branch (dual-channel notification)

1. After the LLM node, add the first MCP node and select the Lansenger MCP “Send Private Message” tool:
   • Recipient references the Environment Variable DUTY_STAFF_ID;
   • Message content references the LLM node’s output.
2. Add a second MCP node and select the “Send Group Message” tool:
   • Group ID references the Environment Variable EMERGENCY_GROUP_ID;
   • Message content references the LLM node’s output.

Note: The two MCP nodes on the P0 branch are serially connected — private message to the on-call person first, then group message to the emergency group. To send in parallel, use a “Batch Processing” node.

P1 Branch (group notification)

After the LLM node, add an MCP node and select the “Send Group Message” tool:

• Group ID references the Environment Variable OPS_GROUP_ID;
• Message content references the LLM node’s output.

P2 Branch (record only)

The P2 branch does not retrieve from the Knowledge Base and does not send notifications. Add an “LLM” node that references the alert data as context — the prompt generates a brief summary (one sentence describing the alert content is enough) — and connect it directly to the Output node for recording.

Step 5: Connect the Output Node

1. All three branches ultimately connect to the “Output” node. The output content references each branch’s processing result:
   • P0/P1: reference the LLM summary and the MCP node’s send result;
   • P2: reference the LLM node’s summary.
2. The Workflow returns the processing result at the end through the “Output” node, traceable in the “Conversation Logs.”

Node Configuration Quick Reference

Step 6: Simulate Webhook Requests for Debugging

A Webhook-triggered Workflow cannot be tested directly with a normal end-to-end debug — you need to simulate the external system’s POST request:

1. In the Webhook Callback node’s configuration, view the callback URL and request-format description provided by the platform.
2. Use a tool (e.g., curl or Postman) to send a simulated request to the callback URL, testing each of the three severities:

# P0 critical alert example
curl -X POST {callback_url} \
  -H "Content-Type: application/json" \
  -d '{"level":"P0","system":"Order Service","content":"Database connection count exceeds threshold","timestamp":"2026-08-04T02:30:00Z"}'

3. Check node by node:
   • Webhook Callback: confirm the node received the complete alert JSON;
   • Conditional Branch: confirm the alert went to the correct severity branch;
   • Knowledge Base: confirm recall snippets are relevant to the alert content;
   • LLM: confirm the summary includes alert info and handling suggestions, with no fabrication;
   • MCP node: confirm the on-call person / emergency group / ops group received the corresponding messages.
4. Each node’s input, output, and errors are visible in the debug details; past runs are in “Debug History.”

Troubleshooting common problems:

Step 7: Save and Go Live

1. Click “Save” to save the Workflow. The pre-publish Checklist automatically checks configuration completeness and logic — fill any gaps as prompted.
2. Click the “Save” button dropdown → “Publish to Application Square,” or enable API access through the “Publish Channels” tab.
3. Copy the Webhook Callback URL and configure it in the external monitoring system’s alert-notification rules, so it automatically calls the callback URL when an alert is generated.
4. After going live, open the app details page → “Conversation Logs” tab to review each alert’s trigger record, severity routing, and notification result.

Tip: In the early days after going live, have on-call staff confirm receipt of notifications and reply with handling results. Verify that severity routing and notification delivery are accurate before letting the alert chain run automatically.

Tuning and Boundaries

Ideas for Extension

• Alert aggregation: Use a “Script Execution” node to aggregate multiple alerts from the same system within a short window, merging them into one notification;
• Auto-recovery detection: When the monitoring system calls the Webhook again on alert recovery, the Workflow routes to a recovery-notification branch based on level;
• Ticketing-system linkage: P0 alerts additionally connect to the ticketing-system MCP to create a ticket, auto-assigning it to the on-call person;
• Multi-channel notification: Beyond Lansenger, use an HTTP Request node to call SMS/email gateways for multi-channel delivery;
• Alert dashboard: Write each alert-handling result to a dashboard system via an HTTP Request, tracking alert trends and response times.