> A more ideal approach could be to expose a simple rest API or webhook that allows for the repo owner to integrate external tooling that is better suited for t

> A more ideal approach could be to expose a simple rest API or webhook that allows for the repo owner to integrate external tooling that is better suited for the purpose of enforcing status checks. That... has existed for years? https://docs.github.com/en/rest?apiVersion=2022-11-28 https://docs.github.com/en/rest?apiVersion=2022-11-28 That was the only thing available before github actions. That was also the only thing available if you wanted to implement the not rocket science principle before merge queues. It's hard to beat free tho, especially for OSS maintainership. And GHA gives you concurrency you'd have to maintain an orchestrator (or a completely bespoke solution), just create multiple jobs or workflow. And you don't need to deal with tokens to send statuses with. And you get all the logs and feedback in the git interface rather than having to BYO again. And you can actually have PRs marked as merged when you rebased or squashed them (a feature request which is now in middle school: https://github.com/isaacs/github/issues/2 https://github.com/isaacs/github/issues/2) > PRs are hardly latency sensitive, so polling a REST API once every 60 seconds seems acceptable to me. There is nothing to poll: https://docs.github.com/en/webhooks/types-of-webhooks https://docs.github.com/en/webhooks/types-of-webhooks