AI-Drafted Status Page Updates

Overview

The first minutes of an incident are exactly when nobody has time to write customer communications. Engineers are triaging, and the status page stays silent. This guide builds a workflow that closes that gap: the moment an incident opens, an AI Enrichment node analyzes it and a Status Page destination posts a drafted update, with your fixed phrasing around the AI-generated parts.

The complete chain looks like this:

Trigger (incident.created) → Filter → Deduplicate → AI Enrichment → Status Page

Every node in this chain is a standard workflow node. The design work is in the guardrails: what the AI is allowed to write, and when a human gets to say yes.

The Guardrail Model

Piping raw model prose to customers is a bad idea, and this workflow never does it. Three guardrails keep the automation trustworthy:

1. The template owns the phrasing. Your fixed, approved wording lives in the message template. AI output only fills defined slots inside it, so the model can inform the update but cannot change its tone or make promises you did not write.
2. Publishing is the human checkpoint. Incidents created by monitors are private by default. Nothing reaches your status page until a teammate publishes the incident to it, either with one click in the dashboard or with uptimyctl incidents publish <uuid>. From that moment on, workflow-generated updates flow to the page and its subscribers automatically. The AI drafts immediately; a human approves the audience.
3. Filter and Deduplicate protect subscribers. Narrow the workflow to high severities and suppress repeats within a window, so customers are never spammed with noise.

Step 1: Trigger

Start with a trigger node subscribed to Incident Created. This fires the workflow the moment a new incident opens, whether from a failed healthcheck, a missed heartbeat, an alert rule, or a manual report.

If you also want the status page to reflect progress and recovery, add workflows (or triggers) for Incident Updated and Incident Resolved with their own message templates. The resolved variant is shown at the end of this guide.

Step 2: Filter

Not every incident deserves a customer-facing update. Add a Filter node and narrow the workflow to what your customers actually need to hear about:

• Severity — typically critical and high only
• Tags — for example, only incidents from checks tagged production
• Specific applications or services — only the customer-facing ones

The Filter node can also check that the incident is still active before proceeding, which is useful in resolved-notification variants and delayed chains.

Step 3: Deduplicate

During a real outage, several checks often fail at once and open related incidents. Add a Deduplicate node to suppress repeat notifications within a configurable window (the default is 300 seconds). Your subscribers get one clear update instead of a flood.

Step 4: AI Enrichment

The AI Enrichment node analyzes the incident context and produces a severity assessment, probable root cause, impact analysis, and recommended next steps. It runs on your own OpenAI API key, which you configure when connecting the node.

The results are exposed to every node after it as Handlebars variables under variables.aiAnalysis.*. That is the bridge to the Status Page node: the analysis becomes template slots you can place inside your fixed phrasing.

Step 5: Status Page Destination

Finish the chain with a Status Page destination node. Configure it with the target status page and a Handlebars messageTemplate. When the workflow reaches this node, it posts the update to the status page and emails verified subscribers.

Writing the Message Template

Templates support Handlebars with helpers if, unless, each, with, eq, ne, gt, and lt, and variables from event.*, variables.application.*, variables.aiAnalysis.*, and metadata.*.

The pattern that works: keep your phrasing fixed and let the AI fill defined slots. Customers read a message in your voice with one precise, AI-written sentence about impact inside it.

We are investigating an issue affecting {{variables.application.name}}. {{variables.aiAnalysis.impactAnalysis}} Our team is working on it and we will post updates here.

For the resolved variant, keep the same structure with recovery phrasing:

The issue affecting {{variables.application.name}} has been resolved. {{variables.aiAnalysis.impactAnalysis}} We apologize for any inconvenience and thank you for your patience.

The Complete Workflow

Putting it all together, the worked example is:

1. Trigger — Incident Created (optionally paired with Incident Updated and Incident Resolved workflows)
2. Filter — severity is critical or high, tags include production, scoped to customer-facing services
3. Deduplicate — suppress repeats within the default 300-second window
4. AI Enrichment — connected with your OpenAI API key; exposes variables.aiAnalysis.* downstream
5. Status Page — target status page selected, messageTemplate set to the fixed-phrasing template above; posts the update and emails verified subscribers

Then, during a real incident: the workflow drafts and stages the update within moments, a teammate reviews the incident and publishes it to the status page, and from that point every subsequent workflow-generated update flows to customers automatically.

Best Practices

• Never let AI output be the whole message. Fixed phrasing with AI slots keeps your public voice consistent.
• Filter aggressively. A status page that only speaks when it matters is one customers trust.
• Keep the Deduplicate node in the chain even if your monitors rarely overlap. It costs nothing on quiet days and saves you during the loud ones.
• Preview every template change with the Test button before enabling the workflow.
• Build the resolved variant too. Closing the loop publicly is as important as the first update.