Compiles for 9. Runs on five, every build.

What each check catches

1. Type-checked. The library's platform files for that target compile, by cross-compiling with no linking. Catches a declaration that went missing from src/lib_c or src/crystal/system, which is invisible to every other job.
2. Audited. An iyi program is cross-compiled for the target and the object is read for the symbols it leaves undefined. Catches a call nothing on that platform supplies, which a type-check cannot see.
3. Run. The object is linked with the target's own toolchain and executed, and what it prints is compared with what the same program printed on the machine that built it. The only check that can fail for a reason the first two cannot reach.

The table

The five that run are x86-64 glibc, x86-64 musl, aarch64 under emulation, aarch64-darwin natively, wasm32-wasi under wasmtime. The rest type-check and have their objects audited, which is a weaker claim, and this page makes the difference visible rather than averaging it into one word.

The two loops, as they are written

for target in x86_64-linux-gnu x86_64-linux-musl aarch64-linux-gnu \
              arm-linux-gnueabihf x86_64-darwin aarch64-darwin \
              x86_64-w64-mingw32 x86_64-windows-msvc wasm32-wasi; do

for target in x86_64-linux-gnu aarch64-linux-gnu x86_64-darwin \
              aarch64-darwin x86_64-windows-msvc x86_64-windows-gnu \
              wasm32-wasi; do

The audit loop writes x86_64-windows-gnu, which is the same platform the type-check loop lists under another of the compiler's names for it. The table above maps the two, and the generator behind it checks its audited set against the one read from the repository's own prose, so a spelling that turns into a real difference fails the build rather than this paragraph.

Where a cross-compiled object goes to be run

One job builds the objects for the other platforms; 5 jobs consume them. They are listed here by their own names, and each appears because it says it needs cross-objects, not because this page decided it was relevant.

• An iyi program, run on musl and on aarch64ubuntu-24.04 / musl, natively / aarch64, under emulation
• What a Windows binary does, twenty timeswindows-2022 / What the object asks Windows for / One string, twenty runs, tallied
• The collector on Windows x86_64windows-2022 / What the collector object asks Windows for / Link and run the Windows collector exercise
• The concurrency runtime on Windows x86_64windows-2022 / What the runtime object asks Windows for / Run isolated TLS probe on Windows
• An iyi program, run on wasm32-wasiubuntu-24.04 / Restore the wasm toolchain / Install wasi-sdk and wasmtime (cache miss)

Windows is in that list and not in the run set, and those are two different statements. The run set is the targets whose output is compared against what the same program printed on the machine that compiled it; Windows binaries are executed all the same, on the machines named beside each job above, and on the rest of the workflow's Windows jobs, which consume no cross-built object because they build their own there:

• iyi, built and run on Windowswindows-2025 / What this machine has / Build the fork's compiler
• The standard library and the collector, gated on Windowswindows-2025 / What this machine has / Build the fork's compiler, then `iyi`
• The standard library's module exercises on Windows, shard ${{ matrix.shard }} of 4windows-2025 / What this machine has / Build the fork's compiler, then `iyi`
• The language's gates, on Windowswindows-2025 / What this machine has / Build the fork's compiler, then `iyi`
• Crystal's compiler specs, on Windowswindows-2025 / What this machine has / Build the fork's compiler

That is 8 jobs on a Windows machine every build, and every one is on the list release waits for, so a red one stops a tag rather than being read after it. The why page says what that means for somebody considering it.