When something breaks
The failure modes we have actually seen — what they mean and what you do
This page collects cases that were measured, not imagined. Each section says what you see first, then what is behind it, and only then what to do.
The one rule that matters when hunting a fault
An observation is not a cause. "My change had no effect" does not mean the setting is being ignored — it can also live somewhere that is never read. Read the file before you build an explanation.
Pairing gives up: "too many requests"
What you see: The setup assistant shows the pairing code, and after roughly a minute it fails — without anyone in meinGPT having done anything wrong.
What is behind it: While the device waits for approval it asks the platform every five seconds. meinGPT rate-limits those requests per IP address, not per device. Behind a corporate NAT all your Outposts share one address — so a dozen machines pairing at once, say after a rollout, blow the window between them.
What you do: Stagger the pairings rather than starting them together. Two or three in parallel are fine. Newer Outpost versions wait this out and ask again instead of giving up — the assistant then feels slower, but pairing completes.
The Outpost reports nothing although it is paired
What you see: meinGPT shows the Outpost as "never connected" or "unreachable", although the application is running on the machine and shows its pairing as active there.
What is behind it: The most common cause is a revoked device key — someone disconnected it in meinGPT, or a second machine was paired to the same Outpost. There is exactly one active key per Outpost; a new pairing invalidates the old one.
The Outpost says so honestly: "The platform refused this device's signature." It keeps its local pairing and does not claim success.
What you do: In meinGPT, check whether this Outpost still has an approved device. If not, pair again on the machine. If you are unsure which machine is current — the fingerprint phrase shown during pairing exists for exactly that, and it appears on both sides.
For our support, when you write to us
For security reasons the platform does not tell the device why it refused — otherwise someone could discover which Outpost identifiers exist by trying. The reason is in our server log. Give us the Outpost's name and the rough time and we will find it.
"This workspace may register one Outpost"
What you see: meinGPT refuses when you add another Outpost.
What is behind it: Not a fault, a quota. Every workspace has a ceiling, and existing Outposts keep running unchanged.
What you do: Remove an Outpost you no longer use, or ask us for a higher limit. The dialog names the number that applies to your workspace.
An Outpost cannot be deleted
What you see: The "Delete Outpost" button is greyed out.
What is behind it: A knowledge collection still points at this Outpost. That is deliberate: deleting would otherwise leave a data source pointing nowhere. The dialog lists what is in the way — before you click, not as an error afterwards.
What you do: Remove or re-point the collections it names.
Deleting and disconnecting are two different things
Revoke access disconnects the machine — immediately, without its cooperation. That is the control for "the laptop is gone". The processed data stays on that machine.
Delete Outpost removes the entry in your organization. If the same Outpost is shared with a second organization it keeps running there — the answer in the dialog tells you which of the two happened.
A setting in app_config.yaml has no effect
What you see: You changed a setting in the data directory, restarted the Outpost, and nothing changed.
What is behind it: app_config.yaml is not an input. It is a generated
diagnostics image of the actual state — for support bundles, so we can see how a
machine is configured. The file says so in its own first lines and is
write-protected.
The real state lives in the application's database and is changed through the console only.
What you do: Make the change in the console. If you cannot find a setting there that the file appears to offer, ask us — the image also carries fields the product does not expose today.
Pointing an Outpost at a different meinGPT instance
What you see: You want to move a machine from a test instance to the production one.
What is behind it: The address belongs to the pairing, not to the configuration file. A paired device talks to the platform that approved it.
What you do: Disconnect on the device and pair again there. The index survives; what is rebuilt is the assignment.
A folder is not being searched
What you see: Search does not find documents from a folder although the console lists it.
What is behind it: Three possibilities, in this order:
- It is not finished indexing. The "Data" tab shows progress per folder. Large estates take hours, not minutes.
- The data source in meinGPT is not released to anyone. The Outpost reads the folder, but who may see it is the platform's decision.
- The machine cannot reach the folder. Network drives hang off the account the application runs under. The "Data" tab names the error per folder rather than swallowing it.
The machine was off
What you see: Answers in meinGPT do not include this Outpost's documents.
What is behind it: Expected behaviour, not a meinGPT outage. With the machine off or the Outpost stopped, only those sources are missing — everything else keeps working.
What you do: The machine should stay on. The Outpost starts itself at login; whether the operating system actually registered that is shown on the "System" tab — which reports what the system answered, not what we asked it for.