Send finished deployments and their gate outcome to DX, so your delivery metrics keep working and show what the gates did.

Availability

Business plan and above. Admins set this up in Admin Console > Integrations. Without the plan the section shows what is included, and you can still view and delete destinations you already made.

Keep your metrics tool, add gates

If your team already measures delivery in DX, you do not have to choose. Prodgator holds a deployment at the gate, and when the deployment finishes it tells DX what happened, including whether a gate approved it, someone bypassed it, or an admin overrode it.

Prodgator sends an event when a deployment on a protected environment finishes with one of these results:

Success
Failure
Rolled back: sent as a second event for the same deployment, with its own reference id.

Deployments on environments no gate holds are not sent. Cancelled deployments are not sent.

Connect DX

In DX, open the admin area and create an API token that can create deployments.
In Prodgator, open Admin Console > Integrations, then Metrics tools, and choose Add DX destination.
Enter your DX instance ( or ) and paste the token.
Choose Check connection. Prodgator sends an empty request that DX refuses for its missing fields, which proves the token works without adding a deployment to your DX data.

An organization can have up to five destinations. The token is stored encrypted and is never shown again. To change it, choose Replace token.

Which hosts Prodgator will call

A destination is an instance name, not a free-form URL. Prodgator only sends to , on port 443. Anything else is refused when you save it and again when a delivery is sent.

What Prodgator sends

Prodgator calls the DX method:

{
  "reference_id": "0b1c2d3e-...",
  "deployed_at": "2026-10-03T09:00:00.000Z",
  "service": { "identifier": "acme/api", "name": "api" },
  "repository": "acme/api",
  "commit_sha": "d1a34f0",
  "environment": "production",
  "success": true,
  "source_name": "Prodgator",
  "source_url": "https://app.prodgator.io/app/gates/...",
  "metadata": {
    "deploymentId": "0b1c2d3e-...",
    "status": "success",
    "provider": "github",
    "gateOutcome": "approved",
    "bypassed": false,
    "overridden": false,
    "reviewersState": "approved",
    "customRuleState": null,
    "policyDecision": "approve"
  }
}

is the repository. is its full name, so DX can match commits for lead time.
is only for a successful deployment. Failures and rollbacks send .
is the deployment id. A rollback uses the id followed by , so DX keeps both events. If Prodgator retries a delivery and DX already has it, DX's answer is treated as delivered.
is one of , , , or . Overrides and bypasses take priority over approvals, so they are easy to count.

Prodgator sends no people: no names, emails, comments or override reasons.

Retries and turning a destination off

A delivery that fails with a timeout, a network error, a rate limit or a DX server error is retried for about half an hour. After the last retry it counts as failed.

Prodgator turns a destination off, and posts a notification to the organization, when:

DX rejects the token or the instance is not found. Replace the token or fix the instance, then turn it on again.
Ten deliveries in a row fail.
The host starts resolving to a private or blocked address.

Deliveries on each destination lists the last 50 attempts for 30 days, with the HTTP status and error.

Jellyfish

Jellyfish accepts deployments through its own API, and support is planned. It is not available yet because Prodgator will only send to an endpoint it has checked against the vendor's documentation. In the meantime, if your pipeline calls Jellyfish's deployment endpoint directly, that keeps working next to Prodgator's gates.

Keep your metrics tool