Comparison

GitHub rulesets vs Fwozen

Q: Can you schedule a GitHub ruleset?

No. Rulesets are static configuration — active, evaluate-only, or disabled — and GitHub has no built-in schedule. The workarounds are a human with a calendar reminder or a scheduled workflow that flips the ruleset through the REST API.

Q: Does branch lock work for a code freeze?

Branch lock blocks pushes and merges, but it is all-or-nothing, admin-only to change, and keeps no record of who locked it or why.

Q: Is a cron GitHub Action good enough?

Sometimes. The failure modes: the check only re-evaluates on pull request events so already-green pull requests stay green, the schedule trigger has a five-minute floor and is throttled on the hour, disabling it in an emergency means pushing YAML during a freeze, and workflow logs age out so it is not audit evidence.

Q: If GitHub ships scheduled rulesets, is Fwozen pointless?

The scheduling half of Fwozen’s value would go away. Slack triggers, non-admin freezes, per-PR exceptions with a TTL, an audit log with an actor, cross-repo campaigns, merge-group safety, and deploy gating would not.

Rulesets are good. Use them. Here’s the wall you hit.

How to freeze a branch with rulesets, for free

Two mechanisms, both free on every GitHub plan. Require a check that cannot pass, or restrict updates outright.

Option A — require a check that will not pass

The gentler option: existing pull requests stay open and reviewable, they simply cannot merge. Create the ruleset with the check freeze required, and never report a result for it.

ruleset.json

{
  "name": "release-freeze",
  "target": "branch",
  "enforcement": "active",
  "conditions": {
    "ref_name": { "include": ["refs/heads/main"], "exclude": [] }
  },
  "bypass_actors": [],
  "rules": [
    {
      "type": "required_status_checks",
      "parameters": {
        "strict_required_status_checks_policy": false,
        "required_status_checks": [{ "context": "freeze" }]
      }
    }
  ]
}

Create it, then delete it to thaw

# Freeze
gh api -X POST repos/acme/api-server/rulesets --input ruleset.json

# List, to find the id
gh api repos/acme/api-server/rulesets --jq '.[] | "\(.id) \(.name)"'

# Thaw
gh api -X DELETE repos/acme/api-server/rulesets/12345

Option B — restrict updates

The blunter option: nothing can update the branch at all, including merges. Swap the rules array for a single update restriction.

rules (Option B)

"rules": [{ "type": "update" }]

Read the effective rules

gh api repos/acme/api-server/rules/branches/main \
  --jq '.[] | {type, source: .ruleset_source, id: .ruleset_id}'

That endpoint is the same one Fwozen reads to decide whether your traffic light is green. If you only take one thing from this page, take that command.

Where it stops working

	GitHub rulesets (free)	Fwozen
Block merges to a branch	Yes — Restrict updates or a required check	Included
Cost	Free	Free to $99
Turn it on for 40 repos at 5pm Friday	Manual, or a script you maintain	One switch
Scheduled or recurring windows	Not included	Yes — timezone- and DST-correct
A non-admin can freeze during an incident	Needs admin	Included
Time-boxed exception for one pull request	Not included	Yes — reason + TTL
Who froze it, when, and why	Not included	Yes — audit log
Also blocks deploys	Not included	Included

Why GitHub can’t schedule this yet

Rulesets are static configuration by design: active, evaluate-only, or disabled. There is no time dimension anywhere in the model, which is why there is no schedule to configure.

The request is not new. GitHub community discussions #16796, #157044, and #180858 cover four years of people asking for a scheduled or time-boxed freeze. As of July 2026 nothing has shipped. GitHub shipped branch lock in October 2022, which is adjacent and not the same thing.

If GitHub ships it

The scheduling half of our value goes away, and we will say so on this page the week it happens.

What would not go away: freezing from Slack during an incident, a non-admin freezing with a reason attached, per-PR exceptions with a time limit, an audit log with a real actor, one switch across forty repositories, merge-group safety, and deploy gating. Those are workflow. Rulesets are configuration. Configuration is the easier half.

The four things people build instead

Ranked fairly, including where each one is genuinely the right answer.

Option 1

Rulesets plus a human with a calendar reminder

WorksFree, no code, no dependencies. Genuinely correct for a handful of repositories.

BreaksSomeone has to be awake, available, and an admin. It does not scale past about ten repositories, and there is no record of the decision.

Option 2

A scheduled GitHub Action that calls the API

WorksFree, versioned, and reviewable. If you have one repository and a strong CI culture, this is a reasonable answer and we will not pretend otherwise.

BreaksFive-minute floor and throttling on the hour, no re-evaluation of already-green pull requests, disabled after 60 days of repository inactivity, per-repo copy-paste, and turning it off during an incident means pushing YAML into a frozen repo.

Option 3

An always-pending gate job

WorksConceptually simple: a required check that only passes when a file says it should.

BreaksEvery pull request shows a permanently pending check, which trains everyone to ignore pending checks. Merge queues and forks both need special handling.

Option 4

A dedicated app

WorksFan-out to open pull requests, schedules, Slack, exceptions, an audit trail, deploy gating, and someone whose job is the edge cases.

BreaksCosts money, and it is another app with access to your organisation. At three repositories that trade is not worth making.

If you have three repos and one admin, use rulesets. We mean that. Fwozen starts paying for itself around repo ten, or the first time an incident happened at 2am and the only person who could freeze main was asleep.

Install on GitHub See pricing

Questions this page exists to answer

Can you schedule a GitHub ruleset?

No. Rulesets are static configuration: a ruleset is either active, evaluate-only, or disabled, and nothing in GitHub turns one on at 17:00 on Friday and off at 09:00 on Monday. The usual workarounds are a calendar reminder for a human, or a scheduled workflow that calls the REST API to flip the ruleset — which is a script you now own.

How do you freeze a branch with GitHub rulesets?

Create a branch ruleset targeting the branch and either require a status check that will never pass, or enable Restrict updates. Both block merges. Remember to check bypass_actors: an empty bypass list is the difference between a freeze and a suggestion. The full commands are above.

Does branch lock work for a code freeze?

It does block pushes and merges, but it is all-or-nothing and admin-only to change, and it gives you no record of who locked it or why. It works for one branch and one admin; it does not work for forty repositories at 5pm on a Friday.

Is a cron GitHub Action good enough?

Sometimes, genuinely. The failure modes in the order people hit them: the check only re-evaluates on pull request events, so a pull request that went green at 19:00 is still green at 20:01 and you need a fan-out to every open pull request; the schedule: trigger has a five-minute floor and gets throttled at the top of the hour; turning it off in an emergency means pushing YAML during a freeze; and workflow logs age out, so it is not audit evidence.

If GitHub ships scheduled rulesets, is Fwozen pointless?

The scheduling half of our value would go away, and we would say so here the week it happened. The other half would not: Slack triggers, non-admin freezes with a reason, per-PR exceptions with a TTL, an audit log with an actor, cross-repo freeze campaigns, merge-group safety, and deploy gating are workflow, not configuration.

Competitor facts last verified: 29 July 2026. We re-check every claim on this page quarterly. Found something out of date? Tell us and we will correct it and say so in the changelog.