Hazel not working: what to check, in order

When rules stop firing, the screen shows the same thing regardless of why: files sitting in a folder that should have been emptied. That single symptom covers at least six unrelated causes, three of which are not faults at all but limits working as designed. Opening the rule editor and adjusting conditions is the natural first move and also the wrong one, because four of the six causes live entirely outside the rule.

Working through them in a fixed order is faster than it looks. Most cases resolve in the first two checks, and both take under a minute.

First, confirm Hazel is actually running

Rules only run while the app is in its running state, and that state can be switched off deliberately or left off after troubleshooting something else. Choosing Stop Hazel from the Hazel menu, or from the status menu if it is enabled, halts everything: no rules run, and no Trash processing happens either. The status menu icon dims to show the stopped state and darkens again when started.

Three levels of switch exist, which is why this check catches so many cases. The app as a whole can be stopped. An individual rule can be disabled. All rules for a given folder can be paused. A rule that was disabled during an experiment three weeks ago looks exactly like a rule that is broken. Hazel 6 also added a pause action, which means one rule can pause processing as part of what it does, so a rule that ran correctly can be the reason later rules did not.

Check all three before touching any conditions.

Second, check the licence state, because the limits are silent

This is the cause that produces the most confusion, because nothing announces it. Without registration the app runs in Evaluation mode for 14 days with everything except rule export available. When those days run out it moves into Demo mode, which monitors one folder and allows two active rules. Import and export are disabled there as well.

Nothing is deleted and no error appears. Rules beyond the limit simply stop doing anything. For someone who set up six folders during a trial and came back a month later, the picture is a working application with most of its work missing, which reads as a bug. The same applies after a major version upgrade if the licence has not been entered into the new version yet.

If the count of folders being processed happens to be one, and the count of working rules happens to be two, stop troubleshooting and check registration.

Third, use the three observation layers in the published order

Once the app is running and licensed, the vendor documents a sequence for finding out why a specific file was not touched, and following it in order avoids guesswork.

Layer	Where it is	What it answers
Rule preview	In the rule editor while editing	Would this rule match, as written
Rule status window	Per monitored folder	Which rule does each file in the folder match
Log	Help > View Logs, or View Log in the status menu	What was actually done to this file

The preview settles the question of whether the condition is wrong. The status window settles the question of whether a different rule is catching the file first, which is the usual answer when a rule looks correct and still does nothing: rules are evaluated in order, and something above it matched. The log settles what happened at the time, and its search field narrows output to one filename. If the log is too sparse to explain the behaviour, debug mode produces far more descriptive output and is the last step before contacting support.

Fourth, if the file is inside a subfolder, this is scope rather than failure

A rule watching a folder does not see what happens inside the folders within it. Downloading a PDF into Downloads triggers the rule. Downloading the same PDF into a folder inside Downloads does not, because subfolder contents are ignored unless rules are told otherwise.

Extending rules downward takes a dedicated rule with one condition that matches any folder and one action, "Run rules on folder contents." That rule appears to do nothing on its own, which is correct: it changes how the other rules apply rather than acting itself. The manual recommends writing rules as though they operate on the top level, testing them there, and then adding the descent rule to widen their reach.

This cause turns up most often after someone reorganises a watched folder into categories. The rules did not change and the files did not change, but the depth did.

When a rule fires but does the wrong thing

A different report needs a different approach: the rule runs, and the outcome is wrong. Files land in the right folder with mangled names, or every third file is skipped, or one folder receives everything.

Rule order is the first suspect again, from the other direction. Rules are evaluated from the top, so a broad rule sitting above a specific one will claim files the specific rule was written for, and the specific rule will look untriggered while the broad one looks overactive. The status window shows this directly, since it lists what each file in the folder matches rather than what was intended.

The second suspect is the pattern itself. Renaming and sorting are driven by patterns built from attributes, date formats and counters, and a date pattern that does not correspond to the format in the filename produces a result that is technically correct and visibly wrong. Running rules manually on a small selection, rather than waiting for the folder to change, shortens the loop between editing a pattern and seeing its effect.

When the problem is the file rather than the rule

Content based conditions fail for reasons that have nothing to do with how the rule is written. A scanned document with no text layer has nothing to match unless recognition is applied, which Hazel 6 does on the fly for PDFs without OCR and for images. An encrypted PDF cannot be read at all until a password is supplied, at which point it is kept in the keychain for later runs.

Locked files are a third case, and Hazel 6 added explicit handling for them. A file that macOS has marked as locked will not be moved or renamed by anything, and the resulting silence looks like a rule that did not match. Checking the file in the Finder's Get Info window separates this from a condition problem in seconds.

Fifth, permissions, which fail quietly and look like breakage

Trash related features require Full Disk Access. The installation process prompts for it, opens System Settings to the right place, and asks for a quit and reopen so the permission takes effect. Skipping the reopen leaves the permission granted but not in use, which produces a convincing imitation of a broken feature.

There is a second permission problem documented by the developer. When an application bundle contains several executables, macOS sometimes requires separate permission for the helpers, and the entry that appears in the privacy list is named as a team ID joined to a bundle ID rather than anything recognisable. Someone who granted access to the app itself will not think to look again, and the list will contain an unfamiliar string that is easy to leave unchecked. After any update that changes behaviour without explanation, the privacy settings are worth reopening and reading in full rather than at a glance.

Notification permission is a separate matter with the same shape. A denied notification prompt means the work happens without any visible confirmation, which reads as nothing happening.

When sync leaves files behind, it is behaving as documented

The Sync action copies items added since the rule last ran, and two properties of it get reported as faults.

It is one way. Files changed in the destination are never copied back, and the manual advises against building mutual sync rules, pointing at dedicated sync software for work that needs conflict handling.

Deletions are not mirrored by default. Deleting an already synced file from the watched folder leaves the copy in place at the destination, because rules act on files that match conditions, and an absent file cannot match anything. The documented workaround matches the containing subfolder instead, since the list of files is a property of the folder, with the side effect that the destination then holds the whole subfolder rather than its contents.

When a file ended up somewhere unexpected

Hazel 6 added a way out of this. Right clicking the file in the Finder and choosing Revert returns it to its original location under its original name, and restores properties including tags and comments.

The important half is what comes after. Reverting a file without changing the rule that moved it means the rule will file it again the next time it runs, and the documentation says so plainly. Revert buys time to fix the condition, it does not resolve anything on its own.

After an upgrade, expect the prompts to come back

Installing a new major version over an older one produces alerts asking for permission to access particular folders, and each one has to be accepted. Rules and settings carry over according to the FAQ, which also recommends keeping backups in case a downgrade becomes necessary. A clean install that appears to have lost every rule is worth checking against those alerts before anything is rebuilt, since a version without file access shows an empty picture rather than an error.

Two habits that prevent most of these reports

Both are cheap and both come from the documentation rather than from preference.

The first is stopping the app while writing experimental rules. The manual gives that as a reason for the stop command existing: rules can be composed and previewed without any risk of them acting on real files halfway through being written. Starting it again afterwards is one menu item, and forgetting to do so is the reason for the very first check in this list.

The second is keeping the rule count low enough to reason about. Every rule is a statement about how files will be named and where they will come from, and those statements go stale without announcing it. A vendor changing the filename of a monthly statement breaks a rule that has worked for three years, and nothing reports it. Reviewing the log once a month and deleting rules that have not fired since the last review keeps the set honest, and it makes the status window readable when something does go wrong.

Collect four facts before contacting support

If the sequence above has not found it, the developer asks for the output of those tools rather than a description. Four things make a support message answerable on the first reply: the macOS version, the Hazel version, the log output filtered to the filename in question with debug mode enabled, and a screenshot of the rule status window for that folder. Support is reached from Help > Contact Support inside the app.

What to change first

Run the two fast checks first, running state and licence mode, because together they explain most reports. After that, read the log before editing a single condition. If the recurring problem is that the log, the folder and the terminal used to inspect it are three separate windows, the thing worth changing is the arrangement rather than the rules: Atriens puts the file list and a terminal in one window, and Compared with other file managers sets out where that sits next to rule based automation.