Job runs failing at the git clone step
Final update
This incident is resolved. Scheduled, CI, and API-triggered job runs that clone from GitHub were failing at the "Clone git repository" step due to an upstream GitHub incident affecting SSH deploy key authentication. GitHub has resolved the underlying issue. Git clone error rates on the dbt platform have returned to normal and remained stable. Job runs are operating as expected, and any runs that failed during the incident can be safely retried. We apologize for the disruption and thank you for your patience.
Timeline
- Resolved · Jul 21, 12:52 UTC
This incident is resolved. Scheduled, CI, and API-triggered job runs that clone from GitHub were failing at the "Clone git repository" step due to an upstream GitHub incident affecting SSH deploy key authentication. GitHub has resolved the underlying issue. Git clone error rates on the dbt platform have returned to normal and remained stable. Job runs are operating as expected, and any runs that failed during the incident can be safely retried. We apologize for the disruption and thank you for your patience.
- Monitoring · Jul 21, 11:45 UTC
GitHub has resolved the upstream incident affecting SSH deploy key authentication. As of approximately 7:45 AM ET (11:45 UTC), git clone error rates have returned to pre-incident levels and job runs are completing normally again. Any runs that failed during the incident can now be retried. We are continuing to monitor to confirm full and sustained recovery before marking this incident resolved.
- Identified · Jul 21, 10:31 UTC
We have identified the cause as an upstream GitHub incident affecting SSH authentication for **deploy keys**. Because the dbt platform uses deploy keys to clone Git repositories, scheduled, CI, and API-triggered runs that clone from **GitHub** are failing at the "Clone git repository" step with a `Permission denied (publickey)` error. Runs that connect to other providers (for example GitLab or Azure DevOps) are **not** affected. This is being addressed on GitHub's side. You can follow their progress here: We are monitoring closely and will provide an update as soon as GitHub's mitigation takes effect or we have more information.
- Investigating · Jul 21, 07:45 UTC
We're investigating an issue with **repository cloning** that is causing **scheduled, CI, and API-triggered job runs to fail at the "Clone git repository" step**. This is impacting **job runs across all regions (multi-tenant and single-tenant)** anytime after **approximately 3:40 AM ET (07:40 UTC)**. The team is working on a resolution and we will provide updates at approximately 15 minute intervals or as soon as new information becomes available.
More from dbt Labs
Full history| Started | Incident | Impact | Duration |
|---|---|---|---|
| Sep 2423:56 UTC | GitLab service disruption | minor | Ongoing |
| Sep 2413:27 UTC | Intermittent BigQuery job failures using Workload Identity Federation in EMEA | minor | 12h 23m |
| Sep 2322:59 UTC | Intermittent dbt deps failures | minor | 4m |
| Sep 1823:31 UTC | Schema Hydration Panic | major | 14h 58m |
| Sep 1014:28 UTC | Intermittent errors on the Discovery API | minor | 2h 17m |
| Sep 1013:46 UTC | Increased error rates associated with dbt MCP and dbt Wizard | minor | 41m |
Also caused by deployment or rollout
All| Started | Vendor | Incident | Impact | Duration |
|---|---|---|---|---|
| Sep 1106:22 UTC | Issues with Workers VPC hostname route resolution on 2026-09-11 | none | 0m | |
| Aug 2014:43 UTC | Intermittent failures creating agent tasks | critical | 9h 54m | |
| Aug 2000:31 UTC | [Medium] Issue with Microsoft Office Integration and Box Edit | major | 1h 13m | |
| Aug 622:22 UTC | Trouble Using Search Bar For Some Admins | minor | 2h 44m | |
| Jul 2220:20 UTC | Some users may have experienced errors when accessing Amplitude. | none | 0m | |
| Jul 909:12 UTC | Shared Embeds and Public Links Unavailable | major | 33m |
Sources: vendors' own status pages, published postmortems and SEC 8-K Item 1.05 filings, read daily. Times as reported. Logos via logo.dev; trademarks belong to their owners.