Deployment Intelligence
Every deployment is an observed change event from CI/CD or the API. Mydle never invents history. Correlations to monitors, browser, logs, traces, alerts, and incidents are labeled Observed / Likely / Unknown — never causation.
Deployment sources
Deployments are reported from your CI after the hosting provider confirms the final state. Report success only when the provider marks the production deployment ready — a passing build or workflow is not a production deployment.
Pointing a provider webhook (for example a Vercel webhook) directly at Mydle is not supported. Dedicated provider integrations and self-serve reporting outside the Reporting API are not available yet.
Reporting API
On plans with API access (Enterprise), POST /api/v1/deployments with a Read & write API key from Settings → API (Authorization: Bearer …). The key decides the workspace. Body fields:
title,status(succeeded,failed,cancelled, …)externalId— the provider's deployment ID. Reporting the same ID again returns the existing record; a redeploy of the same commit has a new ID and a separate record.projectId(must belong to the key's workspace),gitSha,branch,version,environment,environmentKind,startedAt,finishedAt,buildUrl
Missing fields show as em dashes — Mydle never fabricates commits or timestamps.
GitHub Actions
For Vercel, trigger a job on GitHub's deployment_status event, read the deployment from the Vercel API, and report only terminal states (Ready → succeeded, Error → failed, Canceled → cancelled). Do not report from the build workflow's own result.
GitLab CI
Report from a job that runs after the deployment step and only once the target confirms the release, using the same API and API key.
Other providers
Any provider works through the Reporting API. Send at least a title and ideally status, gitSha, and externalId.
Rollback
When a provider marks a deploy as rollback (isRollback or status rolled_back), the release page shows previous deployment linkage and post-window evidence. Recovered alerts or fewer trace errors appear only if observed after the rollback — otherwise Unknown.
Release correlation
Detail pages soft-compose Related Resources: browser sessions, logs, traces, alerts, incidents, API requests, and audit events in the project / post-deploy window when IDs or time links exist. Empty sections stay hidden. Relationship Graph accepts ?deploymentId=.
Release health
For two hours after a deploy, health checks use the deployment's project only: monitors (via open alerts in-window), browser session errors, trace errors (share of errored or timed-out traces), incidents, and alerts. Pass / fail / unknown only — no composite score, and no claim that the deploy caused a result. Deployments without a project stay Unknown, and a check whose query fails says so instead of passing. Results are provisional until the window closes.
Architecture
Compose-only on existing Monitoring, Browser, Logs, Tracing, Incidents, Alerts, AI, Billing, and Auth engines. Storage lives in deployment tables; overview and detail UIs are thin composers. See docs/architecture/deployments.md in the repository for the canonical model.