This page lists the problems people really hit. It starts from what you see. Every fix has the same shape: what you see, why it happens, what to do.
#Pairing and clients
Pairing fails in the browser on a LAN address. Browsers only allow the
cryptography pairing needs in a secure context. So http://192.168.x.x
fails on purpose. Pair over HTTPS. Or pair over localhost on the server
machine itself. See Reachability.
A new pairing code is rejected right away. A code works once, and only
for 15 minutes. Get a fresh one with recued pair on the server machine.
It prints the code, the server's addresses, and the pairing link. The
running server accepts it. Use the code that was printed last: a new code
replaces the old one. A code from a different server, or from a different
database, is not this server's code.
The webclient looks signed in but nothing loads. The client shows the last thing it knew, even when it cannot reach the server. After a server restart or a network change, give it a moment. Then reload. If it still sticks, check that the server is running and can be reached.
A recipe that watches or touches a live page refuses to run. Page triggers, page reads, and page actions need a paired Browser Bridge. The recipe says so before it runs. It does not fail halfway. Pair a Bridge. Or leave that recipe for a machine that has one.
#Recipes and automation
A reactive recipe stopped firing. After it fails several times in a row, the circuit breaker turns the recipe off and tells you. That is on purpose. Fix the cause. Maybe a connection is missing, or an AI step cannot be served. Then turn the recipe on again. It never turns itself back on.
A watcher seems to do nothing. Quiet ticks are silent on purpose. When
a trigger step returns should_run: false, the tick leaves no audit entry
and no output. Silence means "nothing matched". It does not mean "broken".
A condition never matches. The most common cause is quotes around a
value. equal 'closed_won' compares against the quotes too, so it never
matches. Values in condition strings are always bare: equal closed_won.
A guard halts a run you expected to pass. A guard halts when its
condition is met. So "guard": "{{step.deal}} is_null" stops the run
when the deal is missing. Read it as "stop if". Do not read it as "require
that".
#AI
An AI step fails before the recipe starts. The preflight check matched every AI step against your set-up sources. It found no fit. Each source that cannot be used has a reason. Maybe there is no key. Maybe its limit is used up. Maybe it is turned off. Or maybe it cannot do what the step asks. The fix is in Settings → AI/Models. Add a source, or ask for less in the step.
An embedding producer says no embeddings model is set up. Normal AI sources cannot do vector work. Set up the special slot under Settings → AI/Models → Providers → Embeddings. Embedding calls use only that slot. They do not fall back to the free pool or to the fast and quality slots.
Background enrichment never runs. Three switches control it. First, the topic's trust level. Off stays off, and manual stays manual. Nothing turns itself up. Second, the global Pause-AI window. Third, the topic's pool policy. Free-only stalls when the free pool is used up. Check them in that order.
#Connections and vendors
A vendor capability shows "disabled" after enrollment. The provider gave less than the pack needs. Maybe a HubSpot scope is missing. Maybe the Salesforce user profile cannot see an object. Grant it again in your own vendor app, or fix the Salesforce profile. Then enroll again. The warning names what is missing.
CRM data lags behind the vendor. Without a public URL, your server cannot receive vendor webhooks. So it falls back to a regular check against the vendor. The data still arrives, on that schedule. Give the server a public name to get changes at event speed. Salesforce is the exception. Its streaming subscription goes outward, so it works without a public name.
A connection keeps failing after working for months. On an auth failure, one automatic token refresh is tried. If it keeps failing, the grant itself has most likely been revoked or has expired at the provider. Enroll the connection again under the same name. The recipes that depend on it carry on unchanged.
A recipe reports its connection is not bound. The recipe's connection picker was never given a real connection on this install. Open the recipe's configuration and pick one. If the list is empty, enroll one first.
#Backup and restore
Restore refuses with "target not empty". The restore that runs before pairing only targets fresh servers. That is on purpose. It will not write over a server that already has data. On a server in use, restore from Settings → Backup & Recovery instead. That path has its own guards.
Restore refuses with "archive too new". The archive was exported by a newer server version than the one restoring it. Update the server first. Then restore. The other way round works by itself: an older archive moves forward on a newer server.
Wrong recovery key during restore. It bounces cleanly. Nothing is saved. The server stays untouched. Send the right key and it carries on. You do not upload the archive again.
The server did not come back after a restore. The save ends in a restart. Installs with a supervisor come back by themselves. The start-at-login setup the install script makes is one. A server running in a plain terminal window needs starting again by hand.
#Updates
An update seemed to apply, then the old version is running. The start-up health check failed. So the server went back by itself. That is the safety working. It is not a failed rollback. Check the server logs for what broke before you try again. The attempt is written in the update ledger.