# Azure Service Health Integration

Azure Service Health keeps you informed about incidents, planned maintenance windows, and health advisories that affect the Azure services your workloads depend on. This integration routes those notifications to ITOC360 so your on-call team is looped in automatically when something impacts your Azure environment.

### How it works

When a Service Health event occurs — such as a service outage or upcoming maintenance — Azure fires a webhook to ITOC360 via an Action Group. The platform parses the payload and creates an alert. When the issue is resolved on Azure's end, a follow-up webhook with `stage: Resolved` closes the alert automatically.

### Prerequisites

* An active Azure subscription
* Your ITOC360 webhook URL and integration token (available from the Sources page in ITOC360)

### Setup

#### Step 1 — Navigate to Service Health

In the Azure Portal, search for **Service Health** in the top search bar and open it. You'll land on the Service issues view. From here, click **+ Create service health alert** in the toolbar.<br>

<figure><img src="https://4108595529-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FimJRSa33y5Ej6rwXrBeA%2Fuploads%2FU439DGZ7gIgFDxI9XcHw%2Fimage.png?alt=media&#x26;token=f10033ae-c463-48e9-bcf3-60683d6ef81d" alt=""><figcaption></figcaption></figure>

#### Step 2 — Configure the scope

On the **Scope** tab, set the scope level to **Subscription** and select your subscription from the resource browser. Click **Apply**.

<figure><img src="https://4108595529-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FimJRSa33y5Ej6rwXrBeA%2Fuploads%2FfOmcJJqyreKpUMcIi2EA%2FEkran%20Resmi%202026-03-26%2016.45.13.png?alt=media&#x26;token=9cfb53b1-348e-46eb-86f3-7a64ec1a8bb5" alt=""><figcaption></figcaption></figure>

#### Step 3 — Configure the condition

On the **Condition** tab, the signal is automatically set to **Service health** — you don't need to change this. Configure the following:

* **Services** — leave as all services so you catch events across your entire subscription
* **Regions** — leave as all regions, or narrow down to the regions your workloads run in
* **Event types** — select the event types you want to be alerted on: Service issue, Planned maintenance, Health advisories, Security advisories\ <br>

  <figure><img src="https://4108595529-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FimJRSa33y5Ej6rwXrBeA%2Fuploads%2FDsV36ZpdqRAiHfYlWvvd%2Fimage.png?alt=media&#x26;token=368cf783-41a7-4391-a751-f7804a3b08e0" alt=""><figcaption></figcaption></figure>

#### Step 4 — Set up an Action Group

On the **Actions** tab, select **Use action groups** and click **+ Create action group**.

<figure><img src="https://4108595529-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FimJRSa33y5Ej6rwXrBeA%2Fuploads%2FkICv4nKPZcFeo8A5SxdG%2FEkran%20Resmi%202026-03-26%2016.37.59.png?alt=media&#x26;token=4f49f04b-b9b3-4775-81e9-0b43026058f9" alt=""><figcaption></figcaption></figure>

\
On the **Basics** tab of the action group wizard, fill in the details:

* **Action group name** — e.g. `itoc360`
* **Display name** — e.g. `itoc360` (max 12 characters)
* **Region** — choose the region closest to you

<figure><img src="https://4108595529-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FimJRSa33y5Ej6rwXrBeA%2Fuploads%2FOt7mstikv7iwz29cQ6VO%2FEkran%20Resmi%202026-03-26%2016.39.51.png?alt=media&#x26;token=48ab4060-7f67-4af6-9ded-fbd4577c50c2" alt=""><figcaption></figcaption></figure>

Move to the **Actions** tab. Click the **Action type** dropdown and select **Webhook**.

<figure><img src="https://4108595529-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FimJRSa33y5Ej6rwXrBeA%2Fuploads%2FhbNYMspAGcaeZaoAgLnV%2Fimage.png?alt=media&#x26;token=e4dd72e9-c827-47c5-9281-660ff2e614a7" alt=""><figcaption></figcaption></figure>

A side panel will open. Paste your ITOC360 webhook URL in the **URI** field:

```
https://<your-supabase-url>/functions/v1/integrations?token=<your-token>
```

Make sure **Enable the common alert schema** is set to **Yes** — this is required for the integration to parse the payload correctly. Click **OK**.

<figure><img src="https://4108595529-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FimJRSa33y5Ej6rwXrBeA%2Fuploads%2FoAIVvTpfwx9pG3l1lR5p%2FEkran%20Resmi%202026-03-26%2016.40.59.png?alt=media&#x26;token=0a3c7bb9-22fe-457f-93a1-409974b6a796" alt=""><figcaption></figcaption></figure>

Review the action group summary and click **Create**.<br>

<figure><img src="https://4108595529-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FimJRSa33y5Ej6rwXrBeA%2Fuploads%2F6jNwwcA65HTzR2ol5FTS%2FEkran%20Resmi%202026-03-26%2016.41.41.png?alt=media&#x26;token=1243698e-9d3d-4967-8468-b5bde999502e" alt=""><figcaption></figcaption></figure>

#### Step 5 — Finish the alert rule

Back on the alert rule wizard, move to the **Details** tab. Give your rule a name like `service-health-oncall`. Click **Review + create**, then **Create**.

### Verifying the integration

You can test the integration with a curl request without waiting for a real Azure service event:

```bash
curl -X POST "https://<your-url>/functions/v1/events?token=<your-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "schemaId": "Microsoft.Insights/activityLogs",
    "data": {
      "status": "Activated",
      "context": {
        "activityLog": {
          "eventSource": "ServiceHealth",
          "eventDataId": "6fa98c0f-334a-b066-1934-1a4b3d929856",
          "level": "Informational",
          "operationName": "Microsoft.ServiceHealth/incident/action",
          "properties": {
            "title": "Virtual Machines - West Europe",
            "service": "Virtual Machines",
            "region": "West Europe",
            "incidentType": "Incident",
            "stage": "Active"
          }
        }
      }
    }
  }'
```

A successful response returns the created event object with a 200 status. To test automatic resolution, send the same payload with `"stage": "Resolved"`.

### Field mappings

Azure Service Health alerts are delivered using the Common Alert Schema with an `eventSource` of `ServiceHealth`. The platform reads the following fields:

| Azure Field                                        | Platform Field                                                    |
| -------------------------------------------------- | ----------------------------------------------------------------- |
| `data.context.activityLog.eventDataId`             | Fingerprint — ties together alert and resolve events              |
| `data.context.activityLog.properties.stage`        | Alert type — `Active` triggers ALERT, `Resolved` triggers RESOLVE |
| `data.context.activityLog.properties.incidentType` | Priority                                                          |
| `data.context.activityLog.properties.title`        | Alert title                                                       |

#### Incident type to priority mapping

| Azure Incident Type | Platform Priority |
| ------------------- | ----------------- |
| Incident            | HIGH              |
| ActionRequired      | HIGH              |
| Security            | CRITICAL          |
| Maintenance         | LOW               |
| Informational       | LOW               |

### Notes

Service Health alerts resolve automatically. When Azure marks an incident as resolved, the platform receives a follow-up webhook and closes the corresponding alert in ITOC360 without any manual action.

If you want to be notified only about specific event types — for example, only active incidents and not maintenance windows — adjust the **Event types** selection in the Condition step accordingly.
