Comparison
Fwozen vs. legacy freeze tools
What the previous generation gets right, and the five places we do it differently.
This page describes a category rather than naming a vendor. Every statement about Fwozen on it is something you can check in the product or on our security page. Where we cite a limit of GitHub’s, the link goes to GitHub’s own documentation.
What the previous generation does well
They have been running in production for years. Thousands of installs, Marketplace listings with verified-publisher badges, and a support history. Fwozen shipped this year. No feature table cancels that out, and we are not going to pretend it does.
They solve the core problem. A failing status on the pull request, flipped on and off from a web UI or from Slack. That is the right primitive, and it is why the category exists at all.
Several have scheduling and an API. Recurring and one-off windows, and a documented HTTP API with a freeze log. Comparison pages that claim otherwise are wrong, and we will not repeat a claim in order to sell you something.
Some ship surfaces we do not. A Mac menu bar indicator, for one. It is not on our roadmap.
The short version
If your current tool is working, this page probably won’t change your mind.
The people who should keep reading are the ones who hit a repo cap, wanted scheduling without moving up a tier, got surprised by a merge that landed during a freeze, or were asked by an auditor who froze main on 23 December.
Five differences, each one a mechanism rather than a checkmark.
Enforcement you can prove
Fwozen reads GitHub’s effective rules per branch, shows a traffic light with a plain sentence, offers one-click ruleset setup, and runs a reconciler that re-asserts state and reports how long ago it last verified. The point is not the badge; it is that a freeze which was never required on the branch gets caught by us instead of by your incident.
In the older model, making the freeze binding is a separate manual step: an admin-only branch-protection change, per repository, that the tool neither performs nor checks. Until somebody does it, a “freeze” is a red X that anyone with merge rights can click past — and nothing tells you which of your repositories are in that state.
Check runs, not legacy commit statuses
Fwozen writes updatable check runs. There is no per-commit ceiling to hit, the check can carry a reason and an in-PR Request exception button, and we never need administration: write to make it work. Tools built on commit statuses post one status per open pull request, serially, and run into a limit GitHub publishes.
Checked 29 July 2026docs.github.com/rest/commits/statuses
Freezes that hold with merge queues
A pull request that entered the merge queue before the freeze started will otherwise merge after it. When a freeze begins, Fwozen re-evaluates and fails every live merge-group head SHA, so the queue drains into a blocked state. This is the case the category has historically got wrong: a status written only to the pull request head does not govern the merge group GitHub merges.
The features that matter are in every plan
Scheduling, the REST API, and Slack are in our free tier, users are unlimited on every plan, and private repos are unlimited on every paid plan. “Should we enable Fwozen on this repository” should never be a budget conversation, because the answer people give under budget pressure is no, and then the repo is unprotected. The shapes to watch for elsewhere are per-user pricing, and a private-repo cap with a contact-us cliff above it.
An audit log with an actor in it
Every freeze, thaw, and exception in Fwozen carries an actor — GitHub user, Slack user, API key, or the scheduler — plus a source, a reason, and a timestamp. It is append-only, it filters into a shareable URL, and Business exports it as CSV or JSON. Freeze logs in the older tools tend to record a channel (“web”, “slack”) rather than a person, and the person is the field an auditor asks for.
The permissions we ask for
Seven, and you can read them on the GitHub install screen before you accept anything.
| Permission | Level | Why we need it | What this does not allow |
|---|---|---|---|
| checks | write | Create and update the fwozen check run that blocks the merge. | Reading file contents, or writing anything except our own check runs. |
| statuses | write | The legacy fwozen/status mode, for orgs still on classic branch protection. | Reading code, or modifying another app’s statuses. |
| pull_requests | read | List open pull requests so we know which head SHAs to write to. | Reading diffs. We do not request patch contents. |
| contents | read | GitHub requires it to deliver push events and to read the default branch ref. | We never call the contents API for file data. This permission is the single most common misreading of a GitHub App’s scope — see the note below. |
| metadata | read | Repository names and visibility. Mandatory for every GitHub App. | — |
| merge_queues | read | Receive merge_group events so a queued pull request cannot slip through a freeze. | Modifying the queue. |
| Organization members | read | Verify that the person clicking Freeze is in your org. | Reading emails or profile data beyond membership. |
What we never ask for
contents: write— Never, under any circumstance. Fwozen neither reads nor modifies source code, branches, workflows, or secrets. The only things it writes to GitHub are its own check runs and commit statuses, plus a ruleset you explicitly authorize.administration: write— Not in the core set. One-click ruleset setup uses your own admin authorization, which is kept encrypted so the rule can be repaired, and which you can revoke in GitHub at any time.Slack user-token scopes— None. The Slack app is bot-only.Slack message history— None. Fwozen reads its own slash commands and nothing else.issues, workflows, deployments, secrets, packages, actions— None of them.
The comparison worth making is structural. A tool that freezes by toggling branch protection needs Administration: read & write on your repositories for as long as it is installed. Fwozen freezes by writing its own check run, so administration is not in our core permission set at all — one-click ruleset setup borrows your own admin authorization, and you can revoke it in GitHub whenever you like.
How the price is shaped
| The usual shape | Fwozen | |
|---|---|---|
| What you pay for | Seats, or a capped number of repos | Enabled private repos. Users are free |
| Free plan | Often public repos only | 5 private repos, unlimited public |
| Entry paid plan | Repo-capped | $29/mo — unlimited private repos |
| Above the cap | “Contact us” | $99/mo, then $299/mo, self-serve |
| Scheduled freezes | Commonly a paid tier | Free |
| REST API | Commonly a paid tier | Free |
| Slack | Commonly a paid tier | Free |
| Cancel without emailing anyone | Not included | Included |
The repo cliff is the part worth staring at. On a repo-capped plan a 60-repository organisation — an ordinary 100-engineer company — often has nothing left to self-serve.
Moving over is two steps
There is no importer. The compatibility API is shipped; a one-click import of your old repository list and schedules is on the roadmap and not built, so we are not going to draw you a button for it.
- Step 1
Install Fwozen alongside your current tool
Nothing breaks while both are installed: two required checks simply both have to pass. Enable the same repositories, then freeze one branch and watch it land.
- Step 2
Change one base URL
Point your existing scripts at the compatibility namespace. It accepts the same request shapes and returns the same response field names, so the scripts themselves do not change.
# before
BASE_URL=https://your-old-freeze-tool.example/api
# after
BASE_URL=https://api.fwozen.com/api/compat/v1Price match
Paying for a freeze tool today? Show us the invoice and we’ll match it for twelve months. [email protected]
What we don’t have yet
Publishing our own gaps is what makes the section above worth reading.
- Fwozen is in early access. It is live and paid and running in production, but it has months of history rather than years.
- GitHub Cloud only — no GitHub Enterprise Server, GitLab, Bitbucket, or Azure DevOps.
- No Microsoft Teams app. Slack only.
- No Mac menu bar app, and none planned.
- No Terraform provider yet, which we know some of you want first.
- No migration importer. The compatibility API is the migration path today.
- No CLI yet. The REST API and the GitHub Action are what exist.
- Merge-group freezing is implemented and unit-tested, but we have not yet demonstrated it against a live GitHub merge queue.
- Freeze propagation time is not published, because the load test that would let us publish a measured number has not run.
- Deploy gating is a required check plus an Action, not GitHub’s native deployment protection rules.
- SOC 2 is not complete. Type I is targeted for Q4 2026 and we will not claim otherwise.
Checked 29 July 2026docs.github.com — deployments and environments
What people ask before switching
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, so automation written against one of them keeps working after a base-URL change. On the GitHub side you install a new app, because the freeze mechanism is different — check runs rather than commit statuses.
What do the older tools do better?
Years of production history, which we do not have. Marketplace listings with install counts and verified-publisher badges, which we do not have. In one case a Mac menu bar indicator, which we do not have and are not building. If your current tool is working, that history counts for more than a feature table.
Do the older tools have scheduled freezes?
Some do — recurring and one-off. Comparison pages in this category like to claim otherwise, and it is not true. What differs is where scheduling sits in the price list: it is commonly a paid tier, and in Fwozen it is in the free one.
Can they block deployments?
Usually only indirectly: the API exposes a freeze flag and your pipeline has to remember to poll it. Fwozen ships a fwozen/deploy-gate required check and a published Action, so the deploy stops whether or not anyone remembered.
How does the price compare?
Fwozen is priced per enabled private repository with unlimited users, starting at $29/month for unlimited private repos. The pattern to watch for elsewhere is a repo cap with a “contact us” cliff above it, and per-user pricing that makes adding a release manager a budget decision.
Try it against one branch before you decide anything.
External facts on this page last verified: 29 July 2026. We re-check them quarterly. Found something out of date? Tell us and we will correct it and say so in the changelog.