comparison
GitHub rulesets vs Fwozen
Rulesets freeze one branch. Fwozen freezes an organisation, on a schedule, from Slack, with a record of who decided and why, and a per-branch reading of GitHub’s own effective rules that says what it found. The only rule Fwozen ever writes is the one that makes its own check required, and we publish the free commands for saving that yourself.
the wall
Rulesets stop exactly where your release process starts.
Nine things a release team needs a freeze to do. Rulesets do the first one. Everything under it is either a script you now own or an argument you have at 2am.
Freeze one branch, right now
github rulesets
Yes, by creating a ruleset with an empty bypass list.
fwozen
Yes, in one click, with a reason attached.
Freeze forty repositories at once
github rulesets
One ruleset per repository, or an org ruleset you then have to unwind.
fwozen
One switch. A glob counts its matches before you commit to it.
Turn it on at 17:00 Friday, off 09:00 Monday
github rulesets
No time dimension exists. A human with a reminder, or a script you own.
fwozen
A recurring schedule, timezone- and DST-correct. In the free tier.
Let a non-admin freeze during an incident
github rulesets
No, changing a ruleset is an admin action.
fwozen
Freezing is a Fwozen permission. The Release Manager role needs no repo admin.
Let one hotfix through, with a record
github rulesets
Add the person to bypass_actors and hope somebody remembers to remove them.
fwozen
A per-PR exception with a required reason and a TTL that expires itself.
Know whether the freeze would actually hold
github rulesets
Read the effective-rules endpoint yourself, per branch, every time.
fwozen
The same endpoint, read per branch and re-read by a reconciler, reported as what it found.
Stop a queued pull request merging behind you
github rulesets
A ruleset created mid-queue does not govern the live merge group.
fwozen
Every live merge-group head SHA is re-evaluated and failed.
Freeze the deploy as well as the merge
github rulesets
Out of scope. Rulesets govern refs, not pipelines.
fwozen
fwozen/deploy-gate plus an Action and an endpoint your pipeline calls, which refuse it.
Show an auditor who froze main on 23 December, and why
github rulesets
The org audit log names who changed the ruleset. It carries no reason and no TTL.
fwozen
Append-only log with an actor, a source, a required reason, a timestamp and every exception.
the scheduling gap
Four years of people asking. Nothing shipped.
Rulesets are static configuration. A ruleset is active, evaluate-only, or disabled. The model has no time dimension, which is why there is no schedule to configure and no way to add one.
GitHub community discussions #16796, #157044 and #180858 cover four years of requests for a scheduled or time-boxed freeze. As of July 2026 nothing has shipped. Branch lock, from October 2022, is adjacent and not the same thing.
Fwozen ships recurring windows and one-off windows, timezone- and DST-correct, in the free tier.
configuration vs workflow
Rulesets are configuration. A freeze is workflow, and workflow is the harder half.
Freezing from Slack mid-incident, a non-admin freezing with a reason attached, per-PR exceptions that expire themselves, an audit log with a real actor, one switch across forty repositories, merge-group safety, deploy gating. None of that is a setting, which is why no amount of ruleset configuration gets you there.
If GitHub ever ships scheduled rulesets we will say so on this page the week it happens. The other eight rows in the table above would still be ours.
do it free first
Freeze one branch with rulesets, for free.
Both mechanisms, in full. You should not pay us to learn something GitHub gives you. Seeing the whole procedure is the fastest way to price what forty repositories, a schedule and an audit trail would cost you to build.
Option A: require a check that will not pass
The gentler option. Existing pull requests stay open and reviewable, and none of them can merge. Create the ruleset with the check freeze required, and never report a result for it.
{
"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" }]
}
}
]
}# 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/12345Option 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": [{ "type": "update" }]gh api \
repos/acme/api-server/rules/branches/main \
--jq '.[] | {type, source: .ruleset_source}'That endpoint is the same one Fwozen reads to report whether its check is active, required and pinned on a branch. If you only take one thing from this page, take that command.
Now run all of the above per repository, add a scheduler, merge-queue handling, and a record of who decided and why. You have written Fwozen. Or install it in a minute →
the alternatives
The four things people build instead.
Ranked fairly, including where each is the right answer. Three of the four are code you then own and have to maintain during an incident.
option 1
Rulesets plus a human with a calendar reminder
worksFree, no code, no dependencies. Correct for a handful of repositories.
costs youSomeone has to be awake, available, and an admin. It does not scale past about ten repositories. The org audit log records the ruleset change. The reason, the window, and the exception you granted live in a thread somewhere.
option 2
A scheduled GitHub Action that calls the API
worksFree, versioned, and reviewable. With one repository and a strong CI culture this is a reasonable answer, and we will not pretend otherwise.
costs youFive-minute schedule floor and throttling on the hour, no re-evaluation of already-green pull requests, per-repo copy-paste, and GitHub disables it after 60 days of repository inactivity. Turning it off during an incident means pushing YAML into a frozen repo.
option 3
An always-pending gate job
worksSimple. A required check that only passes when a file says it should.
costs youEvery pull request shows a permanently pending check, which trains your whole team to ignore pending checks. Merge queues and forks both need special handling you now maintain.
option 4
A dedicated app, this one
worksA failing check on every open pull request, schedules, Slack, exceptions with a TTL, an audit log with an actor, merge-queue safety, deploy gating, and someone whose job is the edge cases.
costs youCosts money from repo six, and it is another app with access to your organisation. That is why we publish every permission and every API call we make, line by line. Free covers 5 private repos, so you can check the mechanism before you pay for it.
verdict
Fwozen starts paying for itself around repo ten.
Or earlier, the first time an incident happened at 2am and the only person who could freeze main was asleep, or the first time an auditor asked why the December freeze was lifted early and the audit log could only say that a ruleset changed. Three repos and one admin? Use rulesets, with our blessing and our commands above. Everyone else is already maintaining a freeze tool; the only question is whether it is one somebody wrote at 5pm on a Friday.
Free covers 5 private repos forever, and scheduling, Slack and the API are in it. You can find out which side of the line you are on without a card.
questions
Questions this page exists to answer.
Can you schedule a GitHub ruleset?
No. A ruleset is 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. That workflow 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. Then 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, and it is all-or-nothing and admin-only to change. Your organisation’s GitHub audit log does record that the lock happened and who did it. What it cannot record is why, for how long, or which pull request was let through anyway. 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, yes. Here are 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?
No, and we would say so on this page the week it happened. The scheduling half of our value would go away. 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, one switch across forty repositories, merge-group safety, and deploy gating are workflow, not configuration.
External facts on this page last verified: 15 August 2026. We re-check them quarterly. Found something out of date? Tell us and we will correct it and say so in the changelog.