# Health and diagnostics

V2 has no dedicated readiness endpoint, metrics collector, service supervisor or external uptime monitor. Test the actual reader and, separately, the private editor. A green process status, HTTP 200 or successful build answers only one question. None alone proves the intended page, current source or safe audience.

# Reader acceptance matrix

Test a new browser context and an existing cached context, phone/desktop and both themes. A cached old homepage can mask missing deploy assets. An HTTP 200 response may be a soft 404/home fallback. Inspect page identity and requested resource bytes. Check authored remote requests independently of bundled local libraries.

For a reader at your confirmed production URL, a read-only command can inspect status/headers:

curl -I https://docs.example.org/
curl -I https://docs.example.org/reviewed-deep-route/
curl -I https://docs.example.org/a-deliberately-missing-route/

These illustrative paths are not a live installation. Choose an existing deep route and a genuinely absent route on yours. HEAD checks do not exercise JS, layout, search or actual rendered media. Follow them with browser inspection, including console/network failures. Do not put credentials in a command line or paste private URLs into public diagnostics.

# Editor process and perimeter

Use your actual service manager/logs. MarkStack does not start or repair systemd/nginx for you. Default preview and editor are distinct: preview serves generated dist on loopback 3000; editor normally listens on loopback 3001 and manages private content/runtime.

Check unauthenticated protected APIs reject access. A login page being reachable does not mean protected APIs are healthy, nor does an API rejection mean the server is down. Never weaken allowed hosts, grant everyone admin or bind publicly to bypass a failed check.

Restart ends in-memory sessions and resets in-process limiter state. Account writes/auth versions persist. A stale tab can therefore require fresh sign-in; disabling/resetting an account should not be the first response. A session’s idle limit can expire while its absolute lifetime imposes a separate cap. Check actual configured values through the permitted administrator Security panel.

# Administrator diagnostics

These controls are administrator-scoped, not public monitoring APIs. Account/session data belongs to its intended operator audience. Restart loses current publish job/log state; retained audit summaries are not full logs. History pagination is not unlimited retention. Account activity requests use 50 records; general history defaults 50 and clamps 1-100. See Activity and history for source-defined behavior.

Publication status returns recent 80 log lines from a bounded in-memory buffer. Redaction reduces common secret/path exposure; it is not a proof arbitrary diagnostics are safe to share. Review output manually and share the smallest useful excerpt.

# Storage and permission checks

Check free space, inode availability where relevant, filesystem ownership, ancestor traversal permissions and service identity. Private users files are written owner-only; settings/links temp files use 0640. Host/OS ACLs and existing permissions still matter. Do not fix a failure with world-readable/writable accounts or by exposing the private folder through the web server.

A users-file lock conflict reports failure after bounded waiting. Do not delete a lock owned by an active process. The store’s recovery condition includes both a dead process and sufficient staleness; an unreadable/live lock is not safe to force through.

# Audit warning after successful work

An audit append failure can coexist with a completed mutation/publication. Security reports a warning; the server logs the write error. Later successful append clears the in-process warning. A cleared warning does not reconstruct missing historical events.

1. Check whether the original operation already changed its target.
2. Preserve result/error/time rather than repeating the action.
3. Inspect selected runtime path, disk and permissions privately.
4. Repair the storage cause under your maintenance process.
5. Confirm a later legitimate append and record the gap if evidence is needed.

Repeating a password reset, rename or publish can create unwanted effects. History should describe work, not induce duplicate work when its own logging fails.

# Publication failure versus success

Do not assume every failure means unchanged output. Publishing stages distinguishes the swap, restoration and marker cases. Do not click publish again until source/job/current live state are understood.

The publication marker hashes source metadata, not content bytes. Equal-size edits preserving rounded modification times can evade that indicator. Manual CLI build does not record editor publication. For release integrity, compare actual artifact/source hashes with recorded evidence rather than treating the badge as a cryptographic verdict.

# Safe support bundle

Reproduce in disposable synthetic content/accounts when possible. Record timezone/time, service state, selected path labels and whether output changed. Do not publish a build transcript containing private content. A support report should let another maintainer reproduce the failure without access to your private installation.

Automated local tests and browser checks described in Validation limits do not certify production TLS, proxy policy, physical Safari, accessibility or capacity. Those are separate acceptance checks in your environment.