mechanism
How Fwozen holds a freeze
Fwozen writes the check, GitHub owns the rule, and Fwozen verifies the result. Everything below is a mechanism you can check in the product or in a linked primary source, rather than a claim about anybody else.
the model
One GitHub rule, written once. The freeze itself is Fwozen’s check.
A freeze tool that works by rewriting your branch rules holds the permission to rewrite your branch rules, permanently, and its freeze is that rewrite. Fwozen’s freeze is its own check run. The rule only makes that check required, so it is written once and then left alone, whether Fwozen writes it or you do.
before
Fwozen writes the current policy check
It evaluates the real verdict and writes it to every enforcement-relevant commit: each watched branch tip, the head of every open pull request targeting it, and every live merge-group head. A frozen target gets a failing check, never a synthetic success to make setup look tidier.
the step
The rule gets made required
On an installation that has granted repository administration, Fwozen writes the repository ruleset itself, on a branch you enrolled, and never on a repository you have marked as managed as code. Otherwise, and always at organisation scope, it opens the exact GitHub Rules settings page and shows the rule name, target branches and repositories, the context fwozen, the app to pin it to, and the recommendation to leave the bypass list empty. One organisation ruleset where your plan and role allow it; otherwise one per repository, and Fwozen states how many are left rather than hiding the number.
after
Fwozen verifies the ruleset
On return it re-reads GitHub’s effective rules and reports what it found. If a correct rule already exists, setup finishes with zero saves. If one exists but is wrong, Fwozen opens that rule’s edit page and names the mismatch, instead of talking you into a duplicate.
the permissions, exactly
Fwozen asks for Checks and Statuses write; Pull requests, Contents, Metadata, Merge queues, and organisation Members read; and repository Administration write. Installing grants every permission Fwozen asks for, repository administration included. An installation made before Fwozen asked for it keeps its old set until an organisation owner approves, and some never will.
No organisation Administration, and no Contents write. Repository administration: write is the eighth row and buys exactly one thing — the ruleset that makes the fwozen check required. /security carries all eight and says where that one’s rollout stands. We state the list rather than saying “fewer scopes”, because anybody who checks will find every permission we ask for, including organisation Members read. That last one is why a GitHub organisation owner has to be the one who installs the app.
the check run
An updatable check run, not a commit status.
Fwozen blocks merges with a check run named fwozen, patched in place as state changes. The run carries the freeze reason verbatim, the thaw time, and an in-pull-request Request exception button. fwozen/status remains for branches that already require a status context.
The difference that matters on a long-lived pull request is the ceiling, and it is GitHub’s, not ours.
Checked 15 August 2026docs.github.com/rest/commits/statuses
verification
How Fwozen knows the freeze would really block a merge.
Every freeze tool can show you a red X. The harder question is whether GitHub would refuse the merge, and the honest answer has two halves.
Fwozen reads GitHub’s effective rules for each watched branch with GET /repos/{owner}/{repo}/rules/branches/{branch}, the endpoint that collapses repository, organisation and enterprise rulesets into what is in force. Fwozen reports what it found, including when it could not determine the answer.
A reconciler re-asserts state and records when each branch was last looked at, so a green light from last month cannot pass for one from this morning. The same read catches drift after setup.
two questions, never merged into one
Is the check required and pinned? Answerable, and answered per branch: active, required on the branch, and pinned to the Fwozen app’s integration id.
Who can bypass it? Usually not answerable. GitHub rarely discloses a ruleset’s bypass list to the app reading it, and holding repository administration has not been measured to change that. We report missing evidence as unknown. We never turn it into “no bypass actors”, which would be the single most dangerous sentence this product could print.
precedence
When four freezes overlap, the answer is not a coin toss.
A branch can be inside a recurring window, a manual org-wide freeze, a thaw override and a per-PR exception at the same time. Fwozen resolves that with a fixed rank: exception, manual freeze, thaw override, scheduled freeze. The first rank with a live claim wins, and ties resolve toward freezing. There is no priority number to set and no last-writer-wins.
Behaviour flags fold across the whole winning set, restrictively: one winning claim that blocks deploys blocks deploys, one that disallows exceptions disallows them, and the merge queue may drain only if every winner permits it. The pull request shows which claim it was attributed to, chosen deterministically rather than by whichever row the database returned first.
why this is a mechanism and not a detail
The bug this design exists to prevent is the friendly one, where a weaker overlapping claim quietly relaxes a stronger freeze, a merge lands during a freeze, and the log cannot say which rule allowed it. The engine, the API and the dashboard all run the same pure, unit-tested resolution, so all three answer the same question the same way.
the record
Every row has a person in it.
Every freeze, thaw, extension and exception carries an actor, plus a source, a required reason and a timestamp. The actor is a GitHub user, a Slack user, an API key, or the scheduler. The log is append-only, filterable into a shareable URL, and exportable as CSV or JSON on Business. “Who froze main on 23 December, and why” is a query, not an archaeology project.
Per-PR exceptions are part of the same record: a required reason, a TTL that expires itself, sticky or strict behaviour when new commits land, and, where an organisation turns it on, a second person who has to approve before the exception becomes active. The grant and the expiry are both events with an actor.
what we are not claiming
What we are not claiming.
A mechanism page is only worth reading if it also says where the mechanism stops. The longer version lives at /gaps.
That we have production history. Fwozen shipped this year. The established products in this category have years of it, install counts, and verified-publisher badges. No mechanism argument cancels that out, and if your current tool works, that history is a real reason to keep it.
That a verified check means nobody can merge. It means the fwozen check is active, required, and pinned to the Fwozen app on that branch. Bypass actors are a separate question, and one GitHub usually will not answer at all. We report that as unknown rather than as none, and we have measured no improvement from holding repository administration.
That we verify classic branch protection. We do not. The effective-rules endpoint Fwozen reads on every branch reports rulesets, not classic protection, and we have not demonstrated a classic read against a live classic rule. Classic stays guidance only, and Fwozen says so on the branch rather than showing a light it has not earned.
That merge-queue safety is proven. It is implemented and unit-tested. It has not been demonstrated against a live GitHub merge queue, so we claim the mechanism and not the proof.
A propagation number. The load harness has run three times, at 300 repositories and 5,000 pull requests, against a GitHub stub rather than live GitHub, and it has not yet passed its target of p95 under 30 seconds. So there is no measured number to publish, and a number we have not measured would be the easiest sentence on this page to write and the least honest.
That deploy gating is native GitHub blocking. It is a required check plus an Action plus an endpoint your pipeline calls. GitHub’s own custom deployment protection rules need Enterprise for private repositories, which is why ours works differently, and why a deploy job that never calls the gate is never gated.
the rest of the category
Other tools in this space.
Named, briefly, because pretending the category is empty would be the least credible thing on this page. Each claim below carries the date we checked it.
Administration: write permission exists for a second freeze method that toggles protected branches directly.Checked 15 August 2026docs.mergefreeze.com — FAQ
Checked 15 August 2026github.com/marketplace/noship-app
Checked 15 August 2026github.com/marketplace — install counts
questions
What people ask about the mechanism.
Does Fwozen create the required-check rule for me?
On an installation that has granted repository administration: write, it does — one rule, on a branch you enrolled, and never on a repository you have marked as managed as code. What it writes is still only the rule that makes its own check required; the freeze itself is the check run. That is why a per-PR exception needs no rule change, why a repository whose rules live in your Terraform can be enforced with Fwozen writing nothing to it, and why removing Fwozen never touches a rule you wrote. Fwozen asks for no organisation administration in either direction, so organisation-scope enforcement stays a rule you save; there, Fwozen writes the current policy check, opens the right GitHub settings, and verifies the ruleset after you save it. Where that rollout stands is on /security.
Can we keep our existing scripts?
Mostly, yes. Fwozen serves a compatibility namespace that accepts the request shapes and returns the response field names the previous generation of tools used. Automation written against one of them keeps working after a base-URL change. On the GitHub side you install a new app, because Fwozen freezes with a check run rather than a commit status. The compatibility note has the details.
Does the freeze stop a deploy as well as a merge?
It stops the deploy your pipeline asks about. A requested deployment freeze uses a second check, fwozen/deploy-gate, a published Action, and a GET /v1/freeze-state endpoint for pipelines that are not GitHub Actions. The gate refuses the deploy when your workflow calls it. A deploy job that never calls the gate is never gated, and none of this is GitHub’s native deployment protection rules. The gate fails closed, so an unreachable Fwozen stops the deploy rather than waving it through, and the escape hatch is the Action’s own fail-open input. What an outage does, in both directions →
What happens to a pull request already in the merge queue?
When a freeze begins, Fwozen re-evaluates and fails every live merge-group head SHA, so the queue drains into a blocked state rather than merging behind you. That is the mechanism; we have not yet demonstrated it against a live GitHub merge queue, and we do not describe it as proven until we have.
What is in the free tier?
Scheduled and recurring freezes, the Slack app and the REST API, on 5 private repositories and unlimited public ones. Users are unlimited on every plan, and private repositories are unlimited on every paid plan. The whole table is on the pricing page.
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.