A recent database backup failure on GitHub highlighted a common problem: slow or failed CI workflows. Unlike outright failures, slow runs often go unnoticed, leading to wasted resources. A scan of popular open-source repositories revealed widespread inefficiencies in their CI configurations. Many projects lacked crucial settings like concurrency control and job timeouts, resulting in redundant workflows.A significant issue is triggering workflows on both push and pull requests, causing duplicate runs for the same changes. This can be resolved by triggering on pull requests only, except for the default branch. Another common problem is failing to cancel in-progress runs when new code is pushed, leading to wasted queue slots. Implementing concurrency groups with cancel-in-progress set to true can prevent this.Reinstalling dependencies from scratch on every run also adds considerable time. Utilizing the caching feature in setup actions can significantly speed up this process. Overly large matrices, testing on every OS-version combination, can be optimized by running a slimmer matrix for pull requests and the full matrix for the default branch or nightly builds. Not scoping CI triggers to specific file paths means any change, even a typo in documentation, can trigger the entire test suite.Furthermore, jobs without timeouts can hang for hours, consuming excessive resources. Setting a timeout-minutes for each job is essential. Tools are available to scan public repositories and identify these common CI inefficiencies. Checking Actions scorecards for popular projects can also offer insights into best practices. The author provides a free scanner to help identify these patterns in any public repository.