observability-and-instrumentation

Wrap every vault, filesystem, or network operation in a try/catch that shows an Obsidian Notice naming what was attempted and what failed. Log the full stack trace with console.error prefixed by your plugin id so bug reports contain reproducible detail.

Silent failures usually come from empty catch blocks or promises without .catch handlers. Add a Notice for user-triggered failures, log details via console.error, and gate verbose tracing behind a debug logging setting users can enable when reproducing issues.

Obsidian plugin guidelines and this template's privacy stance prohibit undisclosed network calls, so analytics SDKs and crash reporters require explicit disclosure. The recommended approach is on-device diagnostics: Notices for users and console logs for bug reports.

Obsidian's guidelines permit only console.warn, console.error, and console.debug, enforced by eslint-plugin-obsidianmd's no-console override. Prefix messages with your plugin id so they are greppable among output from other installed plugins.

Distributed tracing, metrics backends, and alerting assume a server collecting data from many instances, which a client-side plugin lacks. For Obsidian plugins, use local Notices and console logging instead of reaching for backend observability tooling.