Status, support, release notes, and troubleshooting index

Ethen provides public Platform status, Help, and Contact routes, along with product documentation and troubleshooting pages. Those routes are useful navigation points, but they do not establish uptime guarantees, a formal incident history, 24/7 support, dedicated enterprise channels, response-time SLAs, or a fixed release cadence.

Use this directory to choose the right source for current information and to prepare a concise support request when product-level troubleshooting is not enough.

Platform status

The /platform-status route is the approved status surface. Review the labels and components presented there, but do not infer a contractual uptime percentage, historical incident completeness, maintenance-window process, or machine-readable status API.

A status page can describe visible service state; it does not replace product-specific error evidence. If one request fails while the status page appears normal, inspect the request ID, provider, route, and configuration.

Status interpretation

A component marked available can still reject a specific request because of authentication, policy, provider entitlement, or customer configuration. Conversely, a provider-specific degradation may affect one route without changing every Ethen surface.

Check the status page first for broad conditions, then inspect the product’s own error and configuration. Record the time because a page can change after the incident begins.

No public incident archive, component API, uptime percentage, maintenance calendar, or notification subscription is verified. Do not infer them from the route.

Product state versus service state

A service can be operational while a capability remains Preview, Demo-only, Setup required, or Unavailable. Platform status should not be used to override those product labels. Conversely, a generally available route can be affected by a provider-specific outage.

Check both dimensions before communicating impact.

Local and provider-specific conditions

A customer’s configured provider, Supabase project, local runtime, or network can fail while the public platform remains healthy. Include those dependencies in local monitoring and troubleshooting.

The platform-status route should be read as one source of context, not the final diagnosis for every deployment.

Support

The /help route is the approved starting point for product guidance. Use the relevant documentation and product troubleshooting page before requesting assistance.

No 24/7 support, dedicated enterprise support, phone support, ticket SLA, or guaranteed response time is established. Do not publish an invented support email, portal, or severity process.

Preparing a support request

Provide a concise summary, affected product and route, expected and observed behavior, time, environment, relevant identifiers, exact state or error, and steps already taken. State whether the data shown is live, fixture, sample, demo-only, or unavailable.

Exclude secrets, full provider keys, session tokens, and unnecessary customer content. If the problem concerns a BYOK account, include the provider name and safe credential label, not the raw value.

Help and Contact are assistance paths. They do not create a formal case severity, response time, or dedicated enterprise channel.

Self-service evidence

Before contacting support, reproduce the issue with safe input when possible and gather the exact error, configuration state, data-honesty label, and identifiers. This shortens diagnosis without requiring access to raw customer content.

If reproduction would create risk, cost, or data exposure, report the existing evidence instead of repeating the action.

Boundaries of assistance

Support can clarify product behavior, help identify a configuration boundary, and receive a defect report. It cannot create provider entitlements, recover an external account without the provider, or replace the customer’s incident and legal processes.

State which external system is involved so the request reaches the right owner.

Release notes

Release notes describe shipped changes when an approved record exists. A fixed cadence, automatic generation pipeline, and complete archive are not verified.

Treat a plan, pull request, or interface preview as planned work rather than a shipped release. A release note should identify the affected product and user-visible change without overstating availability.

Shipped versus planned

A shipped release has reached the relevant environment and changes behavior that users can verify. A merged implementation may still require provider configuration or infrastructure before the capability becomes usable. A pull request, design, or roadmap item is planned until it is merged and deployed.

Release notes should preserve capability state. “Added a preview route” is different from “enabled live execution.” “Introduced billing types” is different from “launched billing.”

Because no fixed cadence or automatic release-note pipeline is established, do not promise weekly, monthly, or real-time updates.

A release note should also call out setup changes, migrations, or new review boundaries that affect operators. Adding a route without a configured backend is not the same as making the feature ready. Preserve that distinction in the title and body of the note.

Verification after release

After a relevant change ships, verify the capability in the intended deployment and provider account. A release can require migrations, credentials, or backend configuration before the route becomes usable.

Document that setup separately from the shipped code change and retain preview or unavailable labels until the dependency is satisfied.

Changelog

A changelog is an ordered history of releases or changes. The current evidence does not define a canonical changelog store, immutable ordering, or update schedule.

Where release information is available, prefer the approved product or documentation source. Do not combine draft plans with shipped changes under one status.

Changelog entry fields

A useful entry contains a date or version, affected product, concise change, capability state, migration or setup need, and links to the relevant guide. Security-sensitive details should not expose exploitable internals or secrets.

Corrections should remain traceable where the system supports history. The current evidence does not establish an immutable changelog, so documentation should not imply that every deployment change is recorded.

Avoid mixing marketing announcements, unmerged plans, and technical releases into one ordered history without clear labels.

A changelog correction should identify the original entry and the corrected state. Avoid silently rewriting a historical preview into a generally available release when the capability later matures.

When no canonical release record exists, mark any assembled list as a working reference and verify important changes against the deployed product before relying on it for operations.

Troubleshooting index

Choose the guide that owns the failing boundary:

• identity or route access: Authentication and access control;
• provider or secret configuration: Credential management;
• BYOK routing: BYOK security and operations;
• policy or approval decisions: Policies and enforcement;
• usage and estimates: Usage, billing, and cost controls;
• metrics, traces, or errors: Observability, traces, errors, and evaluations;
• data lifecycle: Data retention and deletion.

Preserve the exact error, route, identifier, product state, and data-honesty label before changing configuration.

If the issue crosses products, begin with the boundary closest to the failure: caller authentication, project ownership, policy, provider, runtime, persistence, or telemetry. This approach avoids changing several configurations at once and losing the original cause.

Escalation

Use /contact when the documented troubleshooting path does not resolve the issue or when a product limitation needs clarification. Include the affected product, route, approximate time, error, request or trace identifier, and the steps already attempted.

Do not include raw credentials or unnecessary sensitive data. Contacting Ethen does not create an incident, vulnerability, support, or response-time SLA.

For an external provider failure, use the provider’s approved support process as well as Ethen’s Contact route when the Ethen routing boundary needs investigation.

Choose the destination

Use product documentation for known setup or usage questions, Help for general guidance, Contact for unresolved product issues, and the external provider’s support path for provider-account or service failures. Security or vulnerability concerns should include minimal safe details through Contact until an appropriate exchange path is agreed.

An escalation needs an owner and a concrete question. “System broken” is less useful than “Gateway request with this identifier was authenticated, then failed before provider selection with this error.”

No severity routing, guaranteed acknowledgement, or resolution timeline is currently documented.

Keep one owner for the escalation and one timeline of updates. When an external provider is involved, note which questions are waiting on the provider and which remain within Ethen. This coordination is a customer operating practice, not a documented Ethen SLA.

Close the escalation with the confirmed cause, remediation, verification, and any documentation or product follow-up. If the cause remains external or unverified, preserve that status instead of reporting a definitive resolution.