Deployments
Firetiger tracks deployment events from your CI/CD systems. A deployment represents a specific Git commit being shipped to a specific environment — for example, commit abc123 going live in production.
You can view your deployment history at /deployments. This shows each deployment event with its repository, environment, Git SHA, and status.
Deployments are a building block for several Firetiger features:
- Change Monitor — proactive, per-PR monitoring that activates when code goes live
- Post-deploy triggers — agent triggers that fire after a specific commit is deployed
How deployments are registered
There are two ways to register deployments with Firetiger.
GitHub Deployments (automatic)
If your CI/CD pipeline uses GitHub Deployments, Firetiger picks up deployment events automatically through your GitHub integration. No extra configuration is needed once the connection is installed.
This auto-creation can be disabled per-connection if your GitHub Deployment events don’t map to meaningful production deploys (e.g., if you use them for CI build gates or preview environments).
Deployment API (explicit)
For other CI/CD systems, or when you want explicit programmatic control, you can register deployments directly via the API:
curl -X POST https://api.cloud.firetiger.com/deployments \
-u "$FT_DEPLOY_USERNAME:$FT_DEPLOY_PASSWORD" \
-H "Content-Type: application/json" \
-d '{
"repository": "owner/repo",
"environment": "production",
"sha": "abc123def456...",
"ref": "main",
"deployer": "octocat",
"deploy_time": "2025-01-15T10:00:00Z"
}'
| Field | Required | Description |
|---|---|---|
repository |
yes | Repository in owner/repo format |
environment |
yes | Deployment environment (e.g. production, staging) |
sha |
yes | Git commit SHA that was deployed |
ref |
no | Git branch or tag that was deployed |
deployer |
no | User or service that triggered the deploy |
deploy_time |
no | RFC 3339 timestamp; defaults to the time of the request |
The optional ref and deployer fields mirror what Firetiger captures from GitHub deployments, so manually-registered deployments show the same branch and deployer context in the Deployments page.
Deploy credentials are available on the Deployments page under the Create a deployment tab.
What happens after a deployment
Once a deployment is registered, Firetiger checks it against any active monitoring plans and post-deploy triggers using Git ancestry.
Git ancestry matching
Firetiger doesn’t require the exact commit from a PR to be deployed. Instead, it checks whether the deployed commit is a descendant of the commit it’s watching. This matters because in practice, the commit that actually gets deployed is rarely the exact merge commit of a single PR — it’s usually a later commit that includes several merged PRs.
For example, suppose you set up Change Monitor on PR #42, which merges as commit B:
PR #42
│
A ── B ── C ── D ── E (main)
│ │
merge of deployed
PR #42 to prod
When commit E is deployed, Firetiger checks: is B an ancestor of E? It is — E contains all the changes from B — so the monitoring plan for PR #42 activates. This works regardless of how many other commits landed between B and E.
Monitoring plans
When a deployment’s SHA is a descendant of a PR’s merge commit, Firetiger marks that PR as deployed and begins running the monitoring plan that was set up for it. Checks run at 10 minutes, 1 hour, and 72 hours after deploy. See Change Monitor for the full guide on setting this up.
Post-deploy triggers
Post-deploy triggers use the same ancestry logic. Each trigger watches for a specific commit SHA (or any descendant of it) landing in a particular repository and environment. When a match is found, the trigger fires the associated agent after a configurable delay. See Post-deploy triggers for details.
Environments
Firetiger doesn’t prescribe a fixed set of environment names. Whatever string you pass as environment — whether that’s production, staging, us-east-1, or canary — is used as-is. This means you can model your deployment topology however it actually works, without mapping it into a predefined set of stages.
When a monitoring plan is tracking multiple environments, it handles them in a single pass. A new deployment to any environment resets the monitoring schedule for the entire plan, since a fresh deploy is a new risk event worth checking against all environments.