Hosted vault is waking slowly

Hosted vaults can park when idle. The next open or edit wakes the hosted daemon runtime and reconnects the editor. A short wake delay is expected; persistent failure is not.

What is normal

• The editor shell remains mounted.
• A wake or loading overlay appears after the hosted runtime has been idle.
• Recently used vault lists, trees, files, or hot documents may load quickly from hosted hot-cache state while colder operations still wake the daemon.
• The vault becomes editable once the hosted daemon control channel is ready.
• Edits made after wake should converge without save errors.

Quick checks

1. Refresh the vault URL once.

2. Confirm your browser is still signed in.

3. Open another note in the same hosted org.

4. If you are an operator, check hosted status:

   GET /api/orgs/<org-slug>/hosted/status

   This is an authenticated Cloud API route for cloud-hosted orgs only.

Operator signals

Hosted lifecycle status can include wake timing, park phase, and control-channel state. Useful symptoms:

Symptom	Likely meaning
Repeated wake overlay	Hosted daemon is starting or waiting for relay control.
Save warning after wake	Runtime woke but document sync or final save failed.
not_hosted_daemon	The org is self-hosted, not Hosted. Use relay troubleshooting instead.
Browser entry rejects lifecycle paths	Expected. Hosted lifecycle controls are private, not browser routes.

When to escalate

Escalate with:

• org slug,
• vault slug,
• time of the slow wake,
• whether a refresh helped,
• any save warning text,
• hosted status if available.

Do not assume slow wake means content loss. Hosted parking is designed to flush and restore daemon state across idle lifecycle transitions.

Also do not assume every fast repeat open means the daemon is currently awake. Hosted hot-cache state can answer a bounded set of repeated reads while the daemon remains the durable authority.

Related docs

• Hosted vaults
• Create a Hosted vault
• Security model