Demo

How it works
Deployments track when a version of an application is deployed to an environment. Each deployment records the version, commit hash, environment, and linked pull requests. Filter deployments by application, environment, and date range to find exactly what you need.Change type
Sweetr automatically determines the change type for each deployment by comparing commits against the previous deployment:- Forward: A standard deployment with new changes.
- Rollback: The deployment reverts to a previous version.
- No Change: A redeployment of the same version.
Deployment triggers
Deployments can be tracked through two different triggers:API Webhook
Send deployments via the POST
/v1/deployments REST endpoint.
Best for custom CI/CD pipelines.
Pull Request Merge
Automatically create a deployment when a pull request is merged to a target
branch. Best for trunk-based development.
Linking Pull Requests
Each deployment is automatically linked to the pull requests it contains. The linking strategy depends on the deployment trigger.API Webhook
When a deployment is received via the API, Sweetr compares the deployment’s commit hash against the previous deployment’s commit hash using GitHub’s compare API. All merged pull requests whose merge commit falls within that range are linked to the deployment. For monorepo applications with a configured subdirectory, only pull requests that modified files within that subdirectory are linked.The first deployment for an application/environment pair is marked as a
baseline and has no linked pull requests, since there is no previous
deployment to compare against.
Pull Request Merge
When a deployment is triggered by a pull request merge, the linked pull request is always the one that was merged. No commit comparison is needed.Data quality
The deployment trigger you choose affects the accuracy of your DORA metrics, specifically Change Lead Time and Deployment Frequency.API Webhook
Records the actual deployment time as reported by your CI/CD pipeline.
This provides the most accurate time-to-deploy calculations since it
captures the real moment your code reaches production.
Pull Request Merge
Uses the merge time as the deployment time. This is an approximation,
since the actual deployment typically happens after the merge — once your
CI/CD pipeline finishes building, testing, and deploying.