How a change lands

It waits for a free check slot, then the check itself (minutes). Only this step catches a change that does not type-check, breaks the lint, or fails a test its own files reach.

• The gate script and the type check, on the pull's head.
• The tests the change reaches (the fast tier), sharded across the check's machine.
• A red main pauses pulls' checks for a while, so a pull is not blamed for main's red.

Measured, last 30 days, public repositories: median time, then how often red.

It waits for a reviewer: an agent for agent pulls, or a person who can write the repository. Only this step catches what no test asks: the wrong change, an unsafe one, or one nobody asked for.

• A verdict counts for the head it was given on; a new push asks for a fresh look.
• Changes asked send the pull back to its builder, who pushes and is checked again.

Measured, last 30 days, public repositories: median time, then how often red.

It waits for the merge queue, which merges approved, green pulls into the default branch in order. Only this step catches a pull that no longer merges onto the base as it is now.

• The merge queue's gate: lint and types on the pull merged with the base's tip.
• A conflicting pull goes back to its builder to rebase before it can land.

Measured, last 30 days, public repositories: median time, then how often red.

It waits for the next release of the default branch. Only this step catches a tree that builds and checks but does not boot or answer as a website.

• The release build, and a boot of the built image on an empty data directory.
• The new version takes over the port only once it answers healthy.
• After the swap the forge loads its own public pages; a failure is paged.

Measured, last 30 days, public repositories: median time, then how often red.