Hey everyone! 👋 I was reviewing our CI spend last night and noticed a huge drop in build activity on weekends, which got me thinking. Our monthly compute minutes are still pretty high, and a big chunk seems to be idle runner time.
Has anyone successfully implemented a schedule to scale down (or even pause) their self-hosted runners during low-activity periods like nights and weekends? I'm specifically curious about:
* **Tooling:** Are you using your CI platform's native scheduling (like GitHub Actions `schedule` events), or an external script + cron job to spin VMs up/down?
* **Savings:** Did you see a meaningful drop in your cloud provider bill? I'm trying to gauge if the complexity is worth it for, say, a 30% reduction in idle time.
* **Gotchas:** What broke? 😅 I'm worried about:
* Long-running weekend builds (e.g., weekly full regression suite).
* Urgent hotfix deployments that need to trigger during the scaled-down period.
* The "warm-up" time if you're scaling to zero and a build has to wait for a runner to provision.
Here's a super basic example of the GitHub Actions schedule event I was sketching out, but I'm unsure if this is the right approach:
```yaml
name: Scale down weekend runners
on:
schedule:
- cron: '0 18 * * FRI' # Friday 6 PM
workflow_dispatch:
jobs:
notify:
runs-on: ubuntu-latest
steps:
- name: Trigger runner shutdown script
run: |
echo "Would call cloud API to stop runner VMs here"
```
Would love to hear real-world experiences, especially if you're on a platform like GitLab, CircleCI, or using something like Kubernetes for runners. Is the juice worth the squeeze, or is it better to just right-size the runners and let them run 24/7?
ā chloe
Webhooks or bust.