How to Forward Vendor System Outage Emails to On-Call with AI Summaries

Point your vendor status-page notification emails at a Spojit Mailhook address, use a Connector node in Agent mode with a Response Schema to pull the affected service, impact level, and ETA out of the message text, log every incident to MongoDB, and route only customer-impacting outages to your on-call Slack channel.

What This Integration Does

Your third-party vendors (payment gateways, cloud hosts, email providers, CDNs) send status notifications by email whenever they degrade or go down. Those messages arrive in inconsistent formats, often buried in a shared inbox, and the on-call engineer either misses them or gets paged for maintenance windows that never touch your customers. This workflow turns that noisy email stream into a clean, structured incident feed: every notification is parsed into the same shape, written to a durable incident log, and only the outages that actually affect customers reach your on-call Slack channel.

The workflow is triggered by a Spojit Mailhook. You forward (or BCC) each vendor's status emails to a dedicated Mailhook address, and a run starts within seconds of the mail arriving. an Agent-mode Connector node extracts the key fields from the raw email body, a record is inserted into MongoDB so you keep a complete history, and a Condition node decides whether to alert. Runs are independent and deduplicated per message, so the same notification arriving twice will not double-page your team. The workflow leaves behind one MongoDB document per notification and, for customer-impacting events, one Slack message in your on-call channel.

Prerequisites

A Slack connection with permission to post to your on-call channel, plus the channel ID or name (for example #oncall-incidents).
A MongoDB connection pointing at the database where you want to store incidents, and a target collection name (for example vendor_incidents).
Access to your vendors' status-page email settings, or a forwarding rule in your shared inbox, so you can send their notifications to a Spojit address.
A workflow created in the Spojit Workflow Designer where you will assemble the nodes below.

Step 1: Create the Mailhook trigger and get your address

Open your workflow in the Workflow Designer and select the Trigger node. Set Trigger Type to Mailhook. Optionally set an Address prefix (1 to 24 characters, default mh) such as vendor-status so the address is recognisable, then click Generate email address. Spojit produces a unique address of the form vendor-status-<random16>@mailhook.spojit.com. Copy it and configure each vendor's status page (or an inbox forwarding rule) to send notifications there. The trigger fires whether the address is in To, Cc, or Bcc, so a BCC on an existing distribution list works well.

The parsed email is available downstream as {{ input }}, including {{ input.from }}, {{ input.subject }}, {{ input.text }}, {{ input.html }}, {{ input.receivedAt }}, and {{ input.replyTo }}. To reduce noise, add a From allowlist listing only your vendors' sending domains, and optionally a Subject regex so marketing mail to the same address is ignored.

Step 2: Extract the outage details with a Connector node in Agent mode

Add a Connector node and switch it to Agent mode. Agent mode lets the agent read the free-form notification and return clean fields, which is exactly what you need when every vendor writes their alerts differently. In the prompt, pass the raw email so the agent has the full context:

You are processing a vendor system-status email. Read the subject and
body below and extract the outage details.

Subject: {{ input.subject }}
From: {{ input.from }}
Body:
{{ input.text }}

Determine the affected service, the impact level, a one-line summary,
and an estimated time to resolution if one is stated.

Set the Response Schema so the node always returns the same structured JSON instead of prose. Use a schema like this:

{
  "type": "object",
  "properties": {
    "vendor":           { "type": "string" },
    "affectedService":  { "type": "string" },
    "impactLevel":      { "type": "string", "enum": ["none", "minor", "major", "critical"] },
    "customerImpacting":{ "type": "boolean" },
    "summary":          { "type": "string" },
    "etaMinutes":       { "type": ["number", "null"] }
  },
  "required": ["affectedService", "impactLevel", "customerImpacting", "summary"]
}

Give the node an Output Variable such as incident. Downstream you can reference {{ incident.impactLevel }}, {{ incident.customerImpacting }}, {{ incident.summary }}, and {{ incident.etaMinutes }}. Forcing a Response Schema is what makes the rest of the workflow reliable: the Condition node and the MongoDB write both depend on these fields existing in a known shape.

Step 3: Log every incident to MongoDB

Add a Connector node on the MongoDB connector in Direct mode and choose the insert-documents tool. Direct mode is right here because the write is deterministic and you do not want to spend AI credits on it. Target your incidents collection (for example vendor_incidents) and map a document that combines the original email metadata with the extracted fields:

{
  "vendor":            "{{ incident.vendor }}",
  "from":              "{{ input.from }}",
  "subject":           "{{ input.subject }}",
  "affectedService":   "{{ incident.affectedService }}",
  "impactLevel":       "{{ incident.impactLevel }}",
  "customerImpacting": "{{ incident.customerImpacting }}",
  "summary":           "{{ incident.summary }}",
  "etaMinutes":        "{{ incident.etaMinutes }}",
  "messageId":         "{{ input.messageId }}",
  "receivedAt":        "{{ input.receivedAt }}",
  "status":            "open"
}

Logging unconditionally, before any alerting decision, means you keep a full audit trail of every notification, including the maintenance windows and minor blips you choose not to page on. Give this node an Output Variable like logged if you want to reference the inserted record later.

Step 4: Branch on customer impact with a Condition node

Add a Condition node after the MongoDB write to decide whether the event deserves a page. Build a condition that checks {{ incident.customerImpacting }} is true and that {{ incident.impactLevel }} is one of major or critical. Connecting the rest of the alerting chain to the true branch ensures the on-call channel only sees outages that matter, while the false branch simply ends the run (the incident is still saved in MongoDB from the previous step). If you prefer, ask Miraxa, the intelligent layer across your automation, to scaffold this for you with a prompt like "Add a Condition node that continues only when {{ incident.customerImpacting }} is true and {{ incident.impactLevel }} is major or critical."

Step 5: Post the alert to your on-call Slack channel

On the true branch, add a Connector node on the Slack connector in Direct mode and choose the send-message tool. Set the channel to your on-call channel (for example #oncall-incidents) and compose a message from the extracted fields so the engineer gets everything at a glance:

:rotating_light: {{ incident.impactLevel | upper }} - {{ incident.affectedService }}

Vendor: {{ incident.vendor }}
Impact: {{ incident.summary }}
ETA: {{ incident.etaMinutes }} min
Reported: {{ input.receivedAt }}

If you want the page to thread, you can follow up with a second Slack node using send-message in the same thread, or enrich the alert later by editing the message with the update-message tool once the vendor posts a resolution. Keep the first message lean so it is readable on a phone at 3am.

Step 6: Optionally request acknowledgement before escalating

If your on-call process requires a human to acknowledge before the workflow continues (for example to update a status board or kick off a follow-up), add a Human node after the Slack alert. Set a clear Label and Message (templated with {{ incident.summary }}), pick an Urgency of High, and add the on-call rota as an Approval slot. Approvers act in the Approvals inbox. Note that a rejection or timeout halts the run, so only add this node when a hard stop on no-acknowledgement is the behaviour you want; otherwise leave the Slack alert as the final step.

Tips

Set the From allowlist on the Mailhook trigger to your vendors' sending domains so newsletters and replies to the address never start a run.
Keep the Response Schema strict and use an enum for impactLevel so the Condition node can compare against fixed values rather than free text.
Store messageId in MongoDB and consider a unique index on it; combined with Mailhook's per-message deduplication, this protects you from duplicate incident records if a vendor resends.
If you watch many vendors, use one Mailhook address per workflow only if their formats differ wildly; otherwise a single address with an allowlist keeps everything in one place.

Common Pitfalls

Vendors frequently send "resolved" and "monitoring" updates as separate emails. Without a clear prompt, the agent may mark a recovery notice as a new outage. Tell it in the prompt to set impactLevel to none for resolution or all-clear messages.
Scheduled maintenance announcements often read as outages. Your customerImpacting field plus the Condition node are what keep these out of Slack; verify the agent treats planned maintenance as not customer-impacting.
If you point too broad a forwarding rule at the Mailhook address, unrelated mail will trigger runs and burn AI credits in Step 2. Tighten the Subject regex and From allowlist first.
The Mailhook trigger is always asynchronous and does not reply to the sender. If you need to acknowledge receipt to a forwarding mailbox, add a Send Email node to {{ input.replyTo }} rather than expecting a synchronous response.

Testing

Before pointing live vendor mail at the address, send a single test email to your Mailhook address that mimics a real outage notification (paste the body of a past incident). Open the workflow's execution history and confirm the run fired, then inspect the Agent-mode node's output to check the Response Schema produced the expected impactLevel and customerImpacting values. Verify a document landed in your vendor_incidents collection in MongoDB. Then send a second test email that describes a minor, non-customer-impacting blip and confirm it is logged but does NOT reach Slack, proving the Condition node routes correctly. Once both cases behave, enable the workflow and forward real vendor notifications.