> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Coolify change integration

> Sync Coolify application deployment results to Flashduty On-call through Coolify's webhook notification channel, as change events you can correlate with alerts and incidents.

<Tip>**Plan requirement**: This feature requires an On-call Standard or higher subscription. [Learn more](https://flashcat.cloud/flashduty/price/)</Tip>

Use Coolify's webhook notification channel to sync application deployment results to Flashduty On-call. Each deployment becomes one Flashduty change, recorded once when the deployment ends.

Coolify sends a notification only when a deployment ends and has no start event, so a change has no Processing state and is recorded directly with its end state: Done or Failed. Coolify sends no notification for a deployment that a user cancels, so no change ends as Canceled.

<div className="hide">
  ## In Flashduty On-call

  ***

  1. In the Flashduty console, go to **Integration Center → Change Events**
  2. Select **Coolify** and enter an integration name
  3. To assign changes to specific channels, add rules under the integration's **Routes** that match labels such as `application`, `project`, or `environment`
  4. Click **Save** and copy the generated **Push URL**
</div>

## Configure Coolify

***

<Steps>
  <Step title="Open the webhook notification channel">
    1. In the Coolify dashboard sidebar, select **Notifications** and open the **Webhook** channel
    2. Paste the full push URL of the Flashduty integration as the webhook URL and save
    3. Turn on the **Enabled** toggle

    Coolify notifications are configured per team: deployments of every project in that team are sent to this URL.
  </Step>

  <Step title="Select events">
    Under **Notification Settings**, select the events for deployment success (`deployment_success`) and deployment failure (`deployment_failed`).

    Selecting other events (backups, scheduled tasks, servers, containers) is harmless: they do not produce changes and are ignored.
  </Step>

  <Step title="Send a test">
    Click the test notification button. Flashduty returns success and records no change. Then trigger a deployment and the change appears in the Flashduty change list.
  </Step>
</Steps>

## What one change is

***

| Coolify object | Change key (change\_key) | Notes |
| - | - | - |
| Deployment | `deployment_uuid` | Each deployment has its own UUID and becomes one Flashduty change. Two deployments of the same application and environment are two changes, and a pull request preview deployment is its own change |

For a multi-server deployment, Coolify sends one notification after all servers finish: the main deployment's UUID when all succeed, or the UUID of the first deployment that did not succeed.

## Status mapping

***

| Coolify `event` | Flashduty change status |
| - | - |
| `deployment_success` | Done |
| `deployment_failed` | Failed |

These deliveries return success and record nothing:

* `test` (test notification)
* `status_changed` and `restart_limit_reached` (application runtime status, not a deployment)
* backup, scheduled task, Docker cleanup, server and container events

## Change content

***

| Field | Content |
| - | - |
| Title | `<application>: deploy to <environment>`; for a pull request preview `<application>: deploy PR #<number> to <environment>`, for example `web-shop: deploy to production` |
| Description | Coolify's notification message, for example `New version successfully deployed` or `Deployment failed` |
| Link | The deployment's log page in Coolify |
| Change time | Coolify's deployment notification has no timestamp field, so the time Flashduty receives the delivery is used |

Labels can be used for routing and for filtering the change list:

| Label | Description |
| - | - |
| `application` | Application name |
| `application_uuid` | Application UUID |
| `project` | Project name |
| `environment` | Environment name |
| `deployment_id` | Deployment UUID |
| `pull_request_id` | Pull request number, only on preview deployments |
| `fqdn` | Application domain, empty when not configured |
| `preview_fqdn` | Preview deployment domain, only on preview deployments |
| `coolify_event` | The raw Coolify event name |

## FAQ

***

<AccordionGroup>
  <Accordion title="Why is there no in-progress state for a deployment?">
    Coolify's webhook notifications are sent only when a deployment succeeds or fails, with no start event. The change appears with its final status when the deployment ends.
  </Accordion>

  <Accordion title="Why is a canceled deployment not recorded?">
    Coolify sends no notification for a deployment a user cancels, so Flashduty receives nothing and no Canceled change is created.
  </Accordion>

  <Accordion title="Does a Coolify retry create a duplicate?">
    A deployment is always the same change, so a retry never creates a second change. The deployment notification has no timestamp, though, so a retried delivery shows up as one more event on the same change, with the same status and result.
  </Accordion>

  <Accordion title="The push returns an InvalidParameter error?">
    * `deployment_uuid is missing`: the payload is incomplete; make sure it comes from Coolify's webhook notification channel
    * `unknown event`: a deployment event name that is not mapped yet; contact us to add it
  </Accordion>
</AccordionGroup>