Admin notification channels (MCP response alerts, vault note, webhook)

[wiverson]

Problem

The server has no way to tell its operator that something needs attention. The failures that matter most are silent: the data volume filling up, the sync daemon dropping into needs-reauth, sync stuck in backoff, or an index rebuild failing. Today you only find out by opening the dashboard, which is exactly what you don't do for weeks at a time.

Deferred for now — logging the design so it doesn't have to be re-derived.

What the platform does not give us

Worth stating plainly, because "Railway alerts" sounds like it covers this and doesn't:

• Railway Monitors are Railway watching your service — thresholds on CPU, RAM, disk usage, network egress → email, in-app, or webhook. Pro plan only. There is no API for an application to raise one, no "notify the project owner" endpoint. On Pro, a disk Monitor at ~80% is the single highest-value alert available and needs no code from us (see Detect low disk headroom and fail writes with a clear message #4).
• Raw SMTP is blocked on Free and Hobby (Pro and above only); Railway's guidance is to use an HTTPS email API instead. So "just point it at an SMTP server" is not viable on the plans this project realistically runs on.

Candidate channels

Each fails differently, so the useful answer is layered rather than picking one.

Channel	Reaches the operator when	Blind spot	Cost
MCP response alert	they're using the vault through an agent	they aren't using it — pull, not push	~60-80 lines
Dashboard banner	they look at the dashboard	they don't look	trivial, surface exists
Vault note (append to e.g. System/ob-sync alerts.md)	~30s later on their phone via Obsidian Sync — genuine push	disk full or sync broken — i.e. the two failures most worth reporting	a file write
Outbound webhook (Slack/Discord/ntfy/Pushover)	always	none configured	~30 lines, one URL setting
HTTPS email API (e.g. Resend, free tier ~3k/mo)	always	none configured	API key needing the same AES-256-GCM storage as the Obsidian credentials

Recommended combination: MCP alerts + dashboard + vault note built in, with an optional webhook URL field for real push. Email adds a secret worth encrypting and buys little over a webhook, so skip unless specifically wanted.

Design sketch for the MCP-response channel

• An alerts module exposing getActiveAlerts() over real conditions: low disk headroom (Detect low disk headroom and fail writes with a clear message #4), sync needs-reauth, sync in backoff beyond N minutes, last index rebuild failed.
• Emit from the existing safe() wrapper in src/server/mcp/server.ts, which every tool already passes through, as one extra content block.
• Deduplicate per credential, resending at most hourly — otherwise a 40-call agent session repeats the same warning 40 times and wastes tokens.
• Keep the text purely factual, never instructional. Something like ⚠ ob-sync: data volume 92% full (410 MB free). Grow the Railway volume before it reaches 100%. Inserting text into tool results that we hope a model relays is structurally the same shape as a prompt-injection payload; it is acceptable because it is first-party and descriptive, and stops being acceptable the moment it starts telling the model what to say. Models relay a clear factual notice on their own.

The plumbing is independent of what triggers it, so it can be built with the sync-health conditions (detectable today) and have #4's disk check drop in later.

Related: #4 (disk headroom detection supplies the most important trigger).

[wiverson]

Deferred past MVP, with the shape decided so it does not need re-deriving:

• an optional pingback URL the server calls with an error message, and
• injecting the error into incoming MCP responses, so the calling model surfaces it during normal use rather than waiting for someone to open the dashboard.

That second one is the interesting half: it reaches the operator through the tool they are already using, which is exactly where a notes server has their attention. Neither is needed to ship.