I already have separate notes on building the Matrix stack, adding MatrixRTC, moving secrets into Vault, changing authentication, and dealing with uploads and backups. The operational question connecting them is simple: what does it mean for the whole stack to work?

It cannot mean that every container is running. Each component can be healthy in isolation while the user-facing path between them is broken.

Start with a path matrix

The acceptance model I use for thinking about the stack separates the following paths:

Path Evidence to look for
Discovery Client obtains the intended service configuration
Authentication A normal user completes the configured login flow
Messaging Two sessions exchange a message and receive it after reconnect
Uploads A permitted file passes the proxy chain and can be downloaded
Calls Two clients exchange media over a supported network path
Recovery Restored application state is usable by a real client

This is a checklist structure, not a claim that a current production instance has just passed every row.

Probe the outer boundary and then narrow down

An internal service response is useful when diagnosing a failure. It does not prove that the public client route, certificate, proxy policy, and application agree.

Uploads make the distinction obvious. An application can accept a given payload size while an earlier proxy rejects it. Raising the limit in only the final service leaves the user-facing behavior unchanged.

The same reasoning applies to timeouts and forwarded headers. Every relevant boundary should have an explicit role, so a failed request can be traced through the chain rather than guessed at.

Test account and token behavior separately from chat

Moving authentication into another service changes more than a login screen. Issuer configuration, callback handling, token verification, and existing sessions all become part of the operational path.

A successful login for an administrator does not establish that ordinary accounts work or that a client can reconnect using its existing session. Those should be separate cases.

The tests should use disposable accounts and avoid embedding real credentials in commands or screenshots.

Calls deserve an end-to-end test

The RTC stack includes more than a web request. Service discovery and authorization can succeed while media transport fails.

An HTTP health check therefore remains a component check. The user-facing evidence is two participants exchanging audio and video, ideally with a network arrangement that exercises the intended connectivity options.

A TURN endpoint being reachable is also narrower evidence than a client actually selecting and using that relay.

Recovery completes the picture

A database dump, configuration directory, and secret inventory are backup inputs. A usable restored service is the result that matters.

A clone needs a safe environment boundary so it cannot send real notifications or accidentally act as the production service. After that, the same path matrix gives a useful recovery acceptance plan.

This makes monitoring and recovery reinforce each other: the paths worth checking during normal operation are also the paths that show whether a restore recovered the application rather than merely its files.