Verify the whole stack

A successful install is not a working bridge, and the failure is quiet in a specific way: ServUO shells out to dotnet build, prints the output, ignores the exit code, and reloads the existing Scripts.dll. A broken script build looks exactly like a clean boot.

So verify each link in the chain, in order. Each check tells you which one to fix.

The plugin compiled — watch the boot output.

Start your shard the way you always do. You want the build to succeed and the bridge to announce itself:
```
Core: Compiling scripts...
Build succeeded.
[Bridge] enabled=True endpoint=127.0.0.1:7788 queueCap=10000 …
```
If you scrolled past it, force the question:
Terminal window
```
dotnet build Scripts/Scripts.csproj -c Release -p:Platform=x64   # must be 0 errors
```
The shard is connected — ask it in game.

As an administrator:
```
[bridge status
```
It reports connected=True depth=0 sent=… dropped=0. connected=False means the shard cannot reach the sidecar. dropped climbing means the sidecar is wedged and the shard is shedding events rather than stalling — which is what it is designed to do, and why a broken bridge never freezes your game.

[bridge reload re-reads Bridge.cfg without a restart; [bridge sweepnow forces one pass of every stream.
The sidecar is healthy — ask it over HTTP.

/health needs no auth, so it is safe to curl on the shard host:
Terminal window
```
curl -s http://127.0.0.1:8080/health
```
```
{"status":"ok","protocol":4,"plugin_connected":true,"database":"ok","uptime":"2m"}
```
plugin_connected: true is the one that matters. It is the only value in this whole sequence that distinguishes “files copied” from “the bridge works”.
The website is ingesting — look at the shard screen.

On the site, open Shard (uo-link) (/admin/uo/link). The header should read Connected, with Shard link: up and WS ingest: online, and the live feed at the bottom should start showing events within seconds rather than sitting on Waiting for shard events….

Then check the public side: the shard status page should stop reporting the game as offline.

When one of them fails

What you see	What it means
Shard boots clean, nothing reaches the site	The classic silent failure — a stale `Scripts.dll`. Run the `dotnet build` line above and read the errors.
`[bridge` is not a command	The plugin did not compile, or the bridge is disabled in `Bridge.cfg`.
`connected=False`	The sidecar is not listening on `127.0.0.1:7788`. Check the service, and that `[shard] bind` matches `Host`/`Port` in `Bridge.cfg`.
`/health` is fine locally, the site says offline	The website cannot reach port 8080 — bind address or firewall. The site is designed to render normally with the shard down, so this fails quietly.
The site logs `409` from the sidecar	Protocol mismatch. Set the Protocol field to what `/health` reports rather than guessing; the sidecar rejects rather than mis-parsing.
`401` from the sidecar	Wrong or missing token. Read the live one back with `uo-link-sidecar --print-config`; do not retype it from a screenshot.

What “working” looks like a week later

The public shard page shows live status, and the admin dashboard shows events arriving.
dropped in [bridge status stays at zero. A climbing number means the sidecar is wedged, not that the shard is unhealthy.
doctor is still green after a shard update — that is what catches an overlay file reverted by hand or by a ServUO upgrade.

You have finished the installation path. From here, Administration covers running the site day to day.