Create HubSpot Tickets Automatically for Incident Management

Turn workflow failures into tracked support tickets automatically. This system blueprint watches every execution across your Kestra instance and, the moment a flow fails or finishes with a warning, opens a high-priority HubSpot ticket enriched with the failing execution ID and timestamp. Instead of failures hiding in logs, they land in HubSpot alongside your other support tickets so customer support, operations, and platform teams get immediate visibility into incidents that touch customer data or business-critical processes.

How it works

1. The on_failure trigger of type io.kestra.plugin.core.trigger.Flow listens to executions across the instance.
2. An io.kestra.plugin.core.condition.ExecutionStatus condition filters for executions in the FAILED or WARNING state.
3. An io.kestra.plugin.core.condition.ExecutionNamespace condition (comparison: PREFIX) limits the trigger to flows whose namespace starts with company, so only the relevant teams generate tickets.
4. When both conditions match, the create_ticket task of type io.kestra.plugin.hubspot.tickets.Create opens a ticket with subject: Workflow failed, content carrying {{ trigger.executionId }} and {{ taskrun.startDate }}, stage: 3, and priority: HIGH.

What you get

• Hands-off incident capture for every failed or warning execution.
• Tickets pre-filled with the execution ID and failure timestamp for fast triage.
• A single namespace prefix filter to scope which flows raise tickets.
• Failures tracked in HubSpot next to customer support work, not buried in logs.

Who it's for

• Customer support teams who need to know when a failure affects customer-facing data.
• Operations and SRE teams tracking pipeline incidents.
• Platform teams owning shared Kestra infrastructure across many namespaces.

Why orchestrate this with Kestra

HubSpot has no awareness of your data pipelines, and your scheduler cannot file a support ticket. Kestra bridges the gap with an event-driven Flow trigger that reacts to the outcome of any execution in real time, no polling required. Declarative YAML keeps the whole incident rule in one readable file, conditions scope it precisely, and built-in retries and execution lineage give you a reliable, auditable trail of which run produced which ticket.

Prerequisites

• A running Kestra instance with the HubSpot plugin available.
• A HubSpot account and a Private App access token or API key with ticket write scope.

Secrets

This blueprint reads the HubSpot credential from a Kestra secret (apiKey: {{ secret('HUBSPOT_API_KEY') }}). Create that secret in your backend with a HubSpot private-app token that has ticket write scope.

Quick start

1. Add this flow to the system namespace (or your equivalent) on your Kestra instance.
2. Set the HubSpot apiKey to your token, ideally via a secret.
3. Adjust the ExecutionNamespace prefix from company to the namespace your team uses.
4. Trigger any flow under that namespace that fails, then confirm a ticket appears in HubSpot.

How to extend

• Change stage and priority to match your HubSpot ticket pipeline.
• Enrich content with more context such as the flow ID, namespace, or a link to the execution.
• Add downstream tasks to notify Slack or page on-call after the ticket is created.
• Broaden or narrow the namespace prefix, or add more ExecutionStatus conditions.

Links

• HubSpot plugin documentation