Diagnostics and support

Collect safe diagnostic information#

Include:

• The page or API route that failed.
• The UTC timestamp and timezone.
• The organization identifier only if your support policy permits it.
• The run ID, action ID, or workflow run ID.
• The HTTP status and a redacted error message.
• The board provider and project reference, if not sensitive.
• Whether the run was dry-run or live.
• The selected cycle letters.
• Browser name and version for UI issues.
• A minimal reproduction sequence.

Do not include:

• Clerk tokens, cookies, or session claims.
• Board API tokens or passwords.
• Stripe secrets, price secrets, customer payment data, or webhook signatures.
• Database URLs or encryption keys.
• Mattermost, Slack, Teams, or n8n webhook URLs.
• Full customer issue descriptions unless support has an approved secure channel.

Health checks for operators#

curl --fail --show-error https://<api-host>/api/health
curl --fail --show-error https://<api-host>/api/readiness

/api/health checks liveness. /api/readiness reports database and configuration readiness. Do not treat an HTTP 200 from the dashboard home page as proof that the API, database, scheduler, or provider integration is healthy.

Browser and device checks#

1. Use a current browser with JavaScript and cookies enabled.
2. Disable extensions that rewrite requests, then retry.
3. Test a private window to isolate cached session state.
4. Confirm the device clock is accurate.
5. For the installable PWA, remove and reinstall the app if a stale service worker persists.

A formal supported-browser matrix has not been approved and needs verification.

Contact support#

The repository does not define a production support email, service-status page, or incident channel. Product owners must replace this notice with approved contact and escalation information before launch.