---
title: "When something breaks"
description: "The failure modes we have actually seen — what they mean and what you do"
canonical_url: "https://meingpt.com/en/docs/integrations/vault/operations/when-something-breaks"
language: en
---

# When something breaks

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.

## Deleting is not the same as disconnecting

**Cut off only** disconnects the *machine* — immediately, without its
cooperation. The **Delete Outpost** dialog offers it while data sources are
still attached to the Outpost. 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.

Registration and deletion limits ("This workspace may register one Outpost", a
greyed-out "Delete Outpost" button) are allowance and admin topics — see
[Allowances in production](/en/docs/admin-guide/outposts#allowances-in-production).

## 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:

1. **It is not finished indexing.** The folder's **Processing** area shows
   progress per folder. Large estates take hours, not minutes.
2. **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.
3. **The machine cannot reach the folder.** Network drives hang off the account
   the application runs under. The folder's **Source documents** area names
   the error per file 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.