Skip to content

Vendor Status Page Relay

Example prompt: "Keep an eye on the status pages of the SaaS tools we depend on, and as soon as one of them reports a major incident, post in #it-alerts on Slack with which internal teams are affected and a short note the helpdesk can send to anyone who raises a ticket about it."

The Problem

When a SaaS vendor we depend on has an outage, the first sign is rarely the vendor's status page — it is three helpdesk tickets in five minutes saying "Slack is down" or "the CRM is throwing errors". The on-duty technician has to confirm whether it is the vendor or our network, find the right status page, work out whether the outage affects the feature the users are using, and then decide who in the company needs to know. By the time the heads-up reaches the affected teams, half of them have already filed their own tickets and the helpdesk queue is full of duplicates of the same issue.

How GloriaMundo Solves It

We build a workflow that runs every 5 minutes. A URL-extract step polls the status-page JSON or the public RSS feed for each tracked vendor — Slack, Google Workspace, the CRM, the design tools, the CI provider. A code step compares the current status to the last-seen status in a state value; only new incidents trigger anything downstream. A conditional step filters out minor or informational notices and proceeds only on incidents the vendor marks as major or critical. An LLM step drafts a one-screen Slack message that names the vendor, the affected component, the vendor's current ETA if any, and which internal teams use that component — pulled from a Google Sheets register of "team uses tool" rows. An integration step posts the message to #it-alerts and, for the components flagged as customer-facing in the register, also pins it to the helpdesk's internal-notes board so the front line has a ready answer when users raise tickets. When the vendor marks the incident resolved, a second pass posts the resolution update. Glass Box preview shows the matched register rows and the drafted message before anything goes to a channel.

Example Workflow Steps

  1. Trigger (scheduled): Every 5 minutes during working hours, every 15 minutes overnight.
  2. Step 1 (url_extract): Fetch the status JSON or RSS feed for each tracked vendor.
  3. Step 2 (state): Compare the current incident list for each vendor against the last-seen list stored in workflow state; produce a delta of new and updated incidents.
  4. Step 3 (conditional): Filter to incidents the vendor marks as major or critical; skip routine maintenance and informational notices.
  5. Step 4 (integration): For each remaining incident, look up the (vendor, component) in the 'Internal Tool Register' tab of Google Sheets to find which internal teams use it.
  6. Step 5 (LLM): Draft a one-screen Slack message — vendor, affected component, vendor's status text, vendor's ETA if any, the affected internal teams, and a short suggested helpdesk reply for users who raise tickets.
  7. Step 6 (integration): Post the drafted message to #it-alerts on Slack, tagging the IT lead and the leads of each affected internal team.
  8. Step 7 (conditional): For components flagged as 'customer-facing' in the register, also write the suggested helpdesk reply to the helpdesk's internal-notes board (Zendesk macro or a pinned note) so the front line has a ready answer.
  9. Step 8 (integration): When the vendor marks the incident resolved, post a follow-up message in the same Slack thread and clear the helpdesk internal note.

Integrations Used

  • Google Sheets — the 'Internal Tool Register' that maps each vendor's components to the internal teams that depend on them
  • Slack — the #it-alerts channel for the broadcast and per-team mentions
  • Zendesk — the internal-notes board where the suggested helpdesk reply is pinned for customer-facing components

Who This Is For

Internal IT teams at companies depending on half a dozen or more SaaS tools where an outage of any one of them puts a real team out of action for the duration, and where the helpdesk currently finds out about vendor incidents from users rather than from the vendor.

Time & Cost Saved

The current pattern — wait for the first three tickets, dig out the status page, confirm it is the vendor, announce it — burns 15-20 minutes of an on-duty technician's time per incident, during the window where the helpdesk is being flooded with duplicates that all need the same reply. This workflow narrows the gap between the vendor publishing the incident and the company knowing about it to under 5 minutes; the duplicate-ticket flood largely does not happen because the affected teams already have the message before they think to raise a ticket.