> For the complete documentation index, see [llms.txt](https://mango-5m.gitbook.io/mango5m-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mango-5m.gitbook.io/mango5m-docs/resources/mango-admin/resource-protection/while-the-panel-is-down.md).

# While the Panel Is Down

What is held for the panel while it is stopped, and what it gets back.

A stopped panel is deaf — which is exactly what somebody who just stopped it wants. So the guard stands in for it, and hands everything over the moment it is back.

## What is held

| Held                               | Written back into                                                         |
| ---------------------------------- | ------------------------------------------------------------------------- |
| Players joining and leaving        | Audit log session lines, join times, last-seen                            |
| Deaths and kills                   | Audit log kill and death lines, killer verified against who was connected |
| `/report <message>`                | The reports queue, filed at the time it was sent, staff notified          |
| Honeypot trips                     | The honeypot log                                                          |
| A telemetry sample a minute        | The performance charts, so the gap has a line rather than a hole          |
| Banned players refused at the door | Audit log, so you know somebody tried                                     |

Everything is written back **dated when it happened**, not when it arrived, and tagged **WATCHDOG** so the record never claims the panel witnessed it.

## Players can still reach staff

`/report <message>` keeps working — the guard registers the command too. `/report` on its own opens a small report window the guard draws itself, because the panel's own window is part of the panel and goes away with it. The player is told their message was received, and it is delivered as soon as the panel is back.

## Bans are still enforced

The connection check lives in the panel, so stopping it would otherwise be the simplest way to walk a banned player in — the one attack this whole resource exists to defeat. The guard holds the door instead, reading the **panel's own ban file** so there is one list and no copy to fall out of date, and showing the same words the panel would have.

Every refusal is logged to the console immediately, pushed to any staff online, and lands in the audit log afterwards.

## Decoys stay armed

The honeypots the panel arms on every client go with it when it stops. The guard arms the same ones in its place — **under the panel's name**, because a cheat menu enumerating exports is looking for `exports.mango_admin:Whatever`, not the guard's. They are disarmed the instant the panel returns, so there is never a duplicate pair.

Decoy **items** are the exception: reading an inventory needs the panel's framework bridge, and a decoy item cannot be obtained legitimately, so it is still sitting there for the panel's next sweep. That one is delayed rather than lost.

## And what the panel already had

Separately from all that, the guard keeps a rolling copy of what the panel holds **only in memory** and would lose by restarting:

| Kept                            | Why it would be lost                               |
| ------------------------------- | -------------------------------------------------- |
| The audit log                   | In memory unless `Config.Audit.persistent`         |
| Population and telemetry charts | Its file is only written every five minutes        |
| Sparklines and the trend arrow  | In memory                                          |
| Everyone's join time            | Otherwise the whole server reads as fresh arrivals |
| A frozen sky or clock           | In memory; clients are told again                  |
| Uptime                          | Otherwise it restarts from zero                    |

Every `Config.Snapshot.EverySeconds` the panel is asked for **only what is new since the last ask**, so on a quiet server most asks carry nothing. On the way back the panel **merges** it — log lines deduplicated on content and renumbered into time order — so running it twice cannot double anything up.

{% hint style="success" %}
**Nothing written just before a stop is lost.** The panel's runtime is still alive while it is stopping, so it hands its whole state over then. Without that, the copy would be up to thirty seconds old and the restore would put back a slightly older log — which reads exactly like your newest lines vanishing.
{% endhint %}

## Where it is kept

The held ledger is written to disk (`data/held.json`), so even a full server restart during an outage still delivers it at the next boot. The copy of the panel's own memory is kept in memory only — what it has to survive is a restart of the panel, and it does.