HTTP Triggers in Azure SRE Agent: From Jira Ticket to Automated Investigation

Introduction

Many teams run their observability, incident management, ticketing, and deployment on platforms outside of Azure—Jira, Opsgenie, Grafana, Zendesk, GitLab, Jenkins, Harness, or homegrown internal tools. These are the systems where alerts fire, tickets get filed, deployments happen, and operational decisions are made every day.

HTTP Triggers make it easy to connect any of them to Azure SRE Agent—turning events from any platform into automated agent actions with a simple HTTP POST. No manual copy-paste, no context-switching, no delay between detection and response.

In this blog, we'll demonstrate by connecting Jira to SRE Agent—so that every new incident ticket automatically triggers an investigation, and the agent posts its findings back to the Jira ticket when it's done.

The Scenario: Jira Incident → Automated Investigation

Your team manages production applications backed by Azure PostgreSQL Flexible Server. You use Jira for incident tracking. Today, when a P1 or P2 incident is filed, your on-call engineer has to manually triage—reading through the ticket, checking dashboards, querying logs, correlating recent deployments—before they can even begin working on a fix. Some teams have Jira automations that route or label tickets, but the actual investigation still starts with a human.

HTTP Triggers let you bring SRE Agent directly into that existing workflow. Instead of adding another tool for engineers to check, the agent meets them where they already work.

Jira ticket created → SRE Agent automatically investigates → Agent writes findings back to Jira

The on-call engineer opens the Jira ticket and the investigation is already there—root cause analysis, evidence from logs and metrics, and recommended next steps—posted as a comment by the agent. Here's how to set this up.

Architecture Overview

Here's the end-to-end flow we'll build:

1. Jira — A new issue is created in your project
2. Logic App — The Jira connector detects the new issue, and the Logic App calls the SRE Agent HTTP Trigger, using Managed Identity for authentication
3. HTTP Trigger — The agent prompt is rendered with the Jira ticket details (key, summary, priority, etc.) via payload placeholders
4. Agent Investigation — The agent uses Jira MCP tools to read the ticket and search related issues, queries Azure logs, metrics, and recent deployments, then posts its findings back to the Jira ticket as a comment

How HTTP Triggers Work

Every HTTP Trigger you create in Azure SRE Agent exposes a unique webhook URL:

https://<your-agent>.<instance>.azuresre.ai/api/v1/httptriggers/trigger/<trigger-id>

When an external system sends a POST request to this URL with a JSON payload, the SRE Agent:

1. Validates the trigger exists and is enabled
2. Renders your agent prompt by injecting payload values into {payload.X} placeholders
3. Creates a new investigation thread (or reuses an existing one)
4. Executes the agent with the rendered prompt—autonomously or in review mode
5. Records the execution in the trigger's history for auditing

Payload Placeholders

The real power of HTTP Triggers is in payload placeholders. When you configure a trigger, you write an agent prompt with {payload.X} tokens that get replaced at runtime with values from the incoming JSON. For example, a prompt like:

Investigate Jira incident {payload.key}: {payload.summary} (Priority: {payload.priority})

Gets rendered with actual incident data before the agent sees it, giving it immediate context to begin investigating.

If your prompt doesn't use any placeholders, the raw JSON payload is automatically appended to the prompt, so the agent always has access to the full context regardless.

Thread Modes

HTTP Triggers support two thread modes:

• New Thread (recommended for incidents): Every trigger invocation creates a fresh investigation thread, giving each incident its own isolated workspace
• Same Thread: All invocations share a single thread, building up a continuous conversation—useful for accumulating alerts from a single source

Authenticating External Platforms

The HTTP Trigger endpoint is secured with Azure AD authentication, ensuring only authorized callers can create agent investigation threads. Every request requires a valid bearer token scoped to the SRE Agent's data plane.

External platforms like Jira send standard HTTP webhooks and don't natively acquire Azure AD tokens. To bridge this, you can use any Azure service that supports Managed Identity as an intermediary—this approach means zero secrets to store or rotate in the external platform. Common options include:

All three support Managed Identity and can transparently acquire the Azure AD token before forwarding requests to the SRE Agent HTTP Trigger.

In this walkthrough, we'll use Azure Logic Apps with the built-in Jira connector.

Step-by-Step: Connecting Jira to SRE Agent

Prerequisites

• An Azure SRE Agent resource deployed in your subscription
• A Jira Cloud project with API token access
• An Azure subscription for the Logic App

Step 1: Set Up the Jira MCP Connector

First, let's give the SRE Agent the ability to interact with Jira directly. In your agent's MCP Tool settings, add the Jira connector:

Configure these environment variables:

MCP Tool configuration panel showing mcp-atlassian@2.0.0 with STDIO transport and environment variables configured

Once the connector is added, select the specific MCP tools you want the agent to use. The connector provides 18 Jira tools out of 80 available. For our incident investigation workflow, the key tools include:

• jira-mcp_read_jira_issue — Read details from a Jira issue by issue key
• jira-mcp_search_jira_issues — Search for Jira issues using JQL (Jira Query Language)
• jira-mcp_add_jira_comment — Add a comment to a Jira issue (post investigation findings back)
• jira-mcp_list_jira_projects — List available Jira projects
• jira-mcp_create_jira_issue — Create a new Jira issue

This gives the SRE Agent bidirectional access to Jira—it can read ticket details, fetch comments, query related issues, and post investigation findings back as comments on the original ticket. This closes the loop so your on-call engineers see the agent's analysis directly in Jira without switching tools.

Step 2: Create the HTTP Trigger

Navigate to Builder → HTTP Triggers in the SRE Agent UI and click Create.

 

Agent Prompt:

A new Jira incident has been filed that requires investigation:

• Jira Ticket: {payload.key}
• Summary: {payload.summary}
• Priority: {payload.priority}
• Reporter: {payload.reporter}
• Description: {payload.description}
• Jira URL: {payload.ticketUrl}

Investigate this incident by:

1. Identifying the affected Azure resources mentioned in the description
2. Querying recent metrics and logs for anomalies
3. Checking for recent deployments or configuration changes
4. Providing a structured analysis with Root Cause, Evidence, and Recommended Actions Once your investigation is complete, use the Jira MCP tools to post a summary of your findings as a comment on the original ticket ({payload.key}).

HTTP Trigger creation dialog showing the name, agent mode, thread mode, and agent prompt with {payload.X} placeholders

After saving, enable the trigger and open the trigger detail view. Copy the Trigger URL—you'll need it for the Logic App.

Step 3: Create the Azure Logic App

In the Azure Portal, create a new Logic App:

Step 4: Enable Managed Identity

In the Logic App → Identity → System assigned:

1. Set Status to On
2. Click Save

Step 5: Assign the SRE Agent Admin Role

Navigate to your SRE Agent resource → Access control (IAM) → Add role assignment:

This grants the Logic App's Managed Identity the data-plane permissions needed to invoke HTTP Triggers.

Important: The Contributor role alone is not sufficient. Contributor covers the Azure control plane, but SRE Agent uses a separate data plane with its own RBAC. The SRE Agent Admin role provides the required data-plane permissions.

Step 6: Create the Jira Connection

Open the Logic App designer. When adding the Jira trigger, it will prompt you to create a connection:

Step 7: Configure the Logic App Workflow

Switch to the Logic App Code view and paste this workflow definition:

{
    "definition": {
        "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
        "contentVersion": "1.0.0.0",
        "triggers": {
            "When_a_new_issue_is_created_(V2)": {
                "recurrence": {
                    "interval": 3,
                    "frequency": "Minute"
                },
                "splitOn": "@triggerBody()",
                "type": "ApiConnection",
                "inputs": {
                    "host": {
                        "connection": {
                            "name": "@parameters('$connections')['jira']['connectionId']"
                        }
                    },
                    "method": "get",
                    "path": "/v2/new_issue_trigger/search",
                    "queries": {
                        "X-Request-Jirainstance": "https://YOUR-SITE.atlassian.net",
                        "projectKey": "YOUR_PROJECT_ID"
                    }
                }
            }
        },
        "actions": {
            "Call_SRE_Agent_HTTP_Trigger": {
                "runAfter": {},
                "type": "Http",
                "inputs": {
                    "uri": "https://YOUR-AGENT.azuresre.ai/api/v1/httptriggers/trigger/YOUR-TRIGGER-ID",
                    "method": "POST",
                    "headers": {
                        "Content-Type": "application/json"
                    },
                    "body": {
                        "key": "@{triggerBody()?['key']}",
                        "summary": "@{triggerBody()?['fields']?['summary']}",
                        "priority": "@{triggerBody()?['fields']?['priority']?['name']}",
                        "reporter": "@{triggerBody()?['fields']?['reporter']?['displayName']}",
                        "description": "@{triggerBody()?['fields']?['description']}",
                        "ticketUrl": "@{concat('https://YOUR-SITE.atlassian.net/browse/', triggerBody()?['key'])}"
                    },
                    "authentication": {
                        "type": "ManagedServiceIdentity",
                        "audience": "https://azuresre.dev"
                    }
                }
            }
        },
        "outputs": {},
        "parameters": {
            "$connections": {
                "type": "Object",
                "defaultValue": {}
            }
        }
    },
    "parameters": {
        "$connections": {
            "type": "Object",
            "value": {
                "jira": {
                    "id": "/subscriptions/YOUR-SUB/providers/Microsoft.Web/locations/YOUR-REGION/managedApis/jira",
                    "connectionId": "/subscriptions/YOUR-SUB/resourceGroups/YOUR-RG/providers/Microsoft.Web/connections/jira",
                    "connectionName": "jira"
                }
            }
        }
    }
}

Replace the YOUR-* placeholders with your actual values. To find your Jira project ID, navigate to https://your-site.atlassian.net/rest/api/3/project/YOUR-PROJECT-KEY in your browser and find the "id" field in the JSON response.

The critical piece is the authentication block:

"authentication": {
    "type": "ManagedServiceIdentity",
    "audience": "https://azuresre.dev"
}

This tells the Logic App to automatically acquire an Azure AD token for the SRE Agent data plane and attach it as a Bearer token. No secrets, no expiration management, no manual token refresh.

After pasting the JSON and clicking Save, switch back to the Designer view. The Logic App automatically generates the visual workflow from the code — you'll see the Jira trigger ("When a new issue is created (V2)") connected to the HTTP action ("Call SRE Agent HTTP Trigger") as a two-step flow, with all the field mappings and authentication settings already configured

Logic App Designer view showing the two-step visual workflow — the Jira "When a new issue is created (V2)" trigger connected to the "Call SRE Agent HTTP Trigger" HTTP action, with the field mappings and Managed Identity authentication visible

What Happens Inside the Agent

When the HTTP Trigger fires, the SRE Agent receives a fully contextualized prompt with all the Jira incident data injected:

A new Jira incident has been filed that requires investigation:

• Jira Ticket: KAN-16
• Summary: Elevated API Response Times — PostgreSQL Table Lock Causing Request Blocking on Listings Service
• Priority: High
• Reporter: Vineela Suri
• Description: Severity: P2 — High. Affected Service: Production API (octopets-prod-postgres). Impact: End users experience slow or unresponsive listing pages.
• Jira URL: https://your-site.atlassian.net/browse/KAN-16

Investigate this incident by:

1. Identifying the affected Azure resources mentioned in the description
2. Querying recent metrics and logs for anomalies
3. ...

• The agent then uses its configured tools to investigate—Azure CLI to query metrics, Kusto to analyze logs, and the Jira MCP connector to read the ticket for additional context. Once the investigation is complete, the agent posts its findings as a comment directly on the Jira ticket, closing the loop without any manual copy-paste.

   

  Jira ticket showing the SRE Agent's investigation summary posted as a comment, with Root Cause, Evidence, and Recommended Actions sections

Each execution is recorded in the trigger's history with timestamp, thread ID, success status, duration, and an AI-generated summary—giving you full observability into your automated investigation pipeline.

HTTP Trigger detail view showing execution history with timestamps, thread IDs, and status for recent trigger invocations

Extending to Other Platforms

The pattern we built here works for any external platform that isn't natively supported by SRE Agent. The core architecture stays the same:

External Platform → Auth Bridge (Managed Identity) → SRE Agent HTTP Trigger

You only need to swap the inbound side of the bridge. For example:

The SRE Agent HTTP Trigger and the Managed Identity authentication remain the same regardless of the source platform. You configure the trigger once, set up the auth bridge, and connect as many external sources as needed. Each trigger can have its own tailored prompt, sub-agent, and thread mode optimized for the type of incoming event.

Key Takeaways

HTTP Triggers extend Azure SRE Agent's reach to any external platform:

1. Connect What You Use: If your incident platform isn't natively supported, HTTP Triggers provide the integration point—no code changes to SRE Agent required
2. Secure by Design: Azure AD authentication with Managed Identity keeps the data plane protected while making integration straightforward through standard Azure services
3. Bidirectional with MCP: Combine HTTP Triggers (inbound) with MCP connectors (outbound) for full round-trip integration—receive incidents automatically and post findings back to the source platform
4. Full Observability: Every trigger execution is recorded with timestamps, thread IDs, duration, and AI-generated summaries
5. Flexible Context Injection: Payload placeholders let you craft precise investigation prompts from incident data, while raw payload passthrough ensures the agent always has full context

Getting Started

HTTP Triggers are available now in the Azure SRE Agent platform:

1. Create a Trigger: Navigate to Builder → HTTP Triggers → Create. Define your agent prompt with {payload.X} placeholders
2. Set Up an Auth Bridge: Use Logic Apps, Azure Functions, or APIM with Managed Identity to handle Azure AD authentication
3. Connect Your Platform: Point your external platform at the bridge and create a test event

Within minutes, you'll have an automated pipeline that turns every incident ticket into an AI-driven investigation.

Learn More

• HTTP Triggers Documentation
• Agent Hooks Blog Post — Governance controls for automated investigations
• YAML Schema Reference
• SRE Agent Getting Started Guide

Ready to extend your SRE Agent to platforms it doesn't support natively? Set up your first HTTP Trigger today at sre.azure.com.