Post an Incident Notice on X with a Human Confirmation Gate

Public incident communication is the one message a company cannot un-send, which is why nobody wants monitoring tooling posting to X on its own. This blueprint automates everything except the decision. An ops webhook opens the execution with the service name and impact in its payload, io.kestra.plugin.core.execution.Fail stops the run while the confirm_public_post input is false, and the resulting Slack alert is the review request, carrying the drafted copy's key facts. A responder reads the copy, then re-executes with confirm_public_post set to true, and io.kestra.plugin.x.XExecution publishes the notice. The task is an execution notification poster, so the post always leads with the execution state and flow id, carries the notice line from customMessage, and ends with a link to the execution, a status-page-style format that fits public incident communication. Posts on X are public and instant, so the human yes is structural, not procedural.

How it works

1. on_incident (io.kestra.plugin.core.trigger.Webhook) receives a POST from monitoring or ops tooling with service_name and impact_summary in the body, and starts an execution with confirm_public_post at its default of false.
2. require_confirmation (io.kestra.plugin.core.execution.Fail) fails the execution whenever confirm_public_post is false, so the webhook path always stops before anything is published.
3. The errors block posts to Slack that the notice is drafted but not published, asking a human to review and re-execute with confirmation. The failure alert and the review request are the same message.
4. On re-execution with confirm_public_post set to true, the gate passes and post_incident_notice (io.kestra.plugin.x.XExecution) publishes the notice using OAuth 1.0a credentials. The task renders its bundled execution template, so the post opens with the execution state and flow id, carries the customMessage notice line, and closes with a link to the execution, and the 280 character cap covers that full rendered post.
5. confirm_internal posts back to Slack that the public notice is live, so the incident channel knows customers have been told.

What you get

• A hard guarantee that no incident copy reaches X without a human setting a boolean to true.
• Draft-and-review built from primitives, the Fail guard drafts, the Slack alert requests review, the re-execution approves.
• Post copy assembled from the ops payload with input fallbacks, consistent across every incident, always framed by the execution state and an execution link.
• A distinct failure signal when the X API call itself fails after approval, so a missing public notice is never mistaken for a pending review.

Who it's for

• SRE and incident response teams who want status posts fast but never automatic.
• Communications owners who must review every public word during an incident.
• Teams replacing a shared doc of incident tweet templates with an executable, audited flow.

Why orchestrate this with Kestra

The confirmation gate only works when it is enforced by the engine, not by convention. Kestra's Fail task makes the guard structural, the errors block guarantees the review request fires every time, and the execution history records who re-executed with confirmation and exactly what was posted, which is the audit trail incident retrospectives ask for.

Prerequisites

• An X developer app with OAuth 1.0a user context credentials for the status account.
• Monitoring or ops tooling able to POST JSON to the webhook URL when an incident opens.
• A Slack incoming webhook in the incident channel.

Secrets

• X_CONSUMER_KEY: X app consumer key (API key).
• X_CONSUMER_SECRET: X app consumer secret (API secret).
• X_ACCESS_TOKEN: OAuth 1.0a access token for the posting account.
• X_ACCESS_SECRET: OAuth 1.0a access secret for the posting account.
• SLACK_WEBHOOK_URL: Slack incoming webhook for review requests and confirmations.
• STATUS_WEBHOOK_KEY: secret key guarding the incident webhook endpoint.

Quick start

1. Add the six secrets to your Kestra namespace.
2. Execute the flow with default inputs and confirm the execution fails at the gate and Slack receives the review request.
3. Re-execute with confirm_public_post set to true and confirm the notice appears on the X account, then delete the test post.
4. Wire the monitoring tooling to the webhook URL.

How to extend

• Post the resolution follow-up when the incident closes, as shown in the resolved notice blueprint.
• Route the review request to a paging tool instead of Slack for severity-one incidents.
• Add a severity field from trigger.body and only require confirmation below a given severity.
• Mirror the notice to the status page API in a task after post_incident_notice, so both channels update together.

Links

• X plugin documentation
• XExecution task reference