Support hub

What is happening

The console's /sign-in page hands you to Triangle (the shared sign-on), then exchanges the session at /api/auth/session and lands you on the console home. A loop means one step in that chain completed and the next one refused.

Check, in order

1. Cookies are allowed for the console domain. The session lives in hardened cookies — httpOnly, Secure, same-site. A browser or extension blocking them lets the sign-on succeed and the exchange fail silently.
2. Do one full fresh sign-in. Sessions are short-lived and rotate continuously; a tab that held an old session can loop on a credential that no longer verifies. Sign out, close the tab, sign in again.
3. Confirm your account is linked. The exchange resolves your platform identity — role, tier, brand memberships — and refuses an identity with no link. It never auto-creates accounts. If you were never provisioned, no amount of re-signing-in helps: request access from the public site or ask your brand's admin.

If you can sign in on one device but not another, the difference is almost always cookie policy on the failing device.

Deeper reading

Triangle: secure sign-on covers the public-to-console handoff; Triangle sessions & tokens covers the exchange, lifetimes, and storage discipline.

What is happening

Console API routes resolve the caller through resolveApiScope: the Triangle session is verified server-side, and when no valid session is present the route returns 401. A 401 is an identity answer — the request carried no credential the platform would verify.

Common causes

• The session expired between page load and the call. Access tokens live on the order of minutes and refresh tokens rotate on every use — a presented old refresh token is no longer valid. Long-idle tabs are the classic case.
• The request does not carry the session cookie. Cross-origin fetches, server-to-server calls, or a client that strips cookies will 401 no matter how fresh the sign-in was.
• You are hitting production behavior in a local checkout. The mock auth provider exists for local console development only; outside it, routes require a real Triangle session.

The fix

Sign in again at the console's /sign-in, then retry. If you integrate against the API directly, refresh proactively just before token expiry and send credentials with every request — tokens travel in headers and cookies, never in URLs.

Triangle sessions & tokens documents lifetimes, rotation, and revocation.

What is happening

Sign-on establishes who you are. What you may do is resolved separately, per brand: sensitive console routes check your grants server-side through Triangle's RBAC (identityCan), scoped to the brand and resource you are acting on. A refusal means the grant check answered no — and the check fails closed, so an error resolving your permissions also answers no.

Common causes

• You are in the wrong brand context. Permissions attach to the brand you are working in, never to your identity globally. Access on one brand says nothing about another.
• Your role changed but grants have not caught up — a grant change is an explicit administrative action, not a side effect of a title change.
• You were never granted this specific action. Viewing a surface and mutating it are separate grants (read versus manage).

The fix

Confirm the brand context in the console, then ask that brand's administrator to review your grants. There is no self-serve elevation — that is deliberate, not a missing feature.

Triangle: secure sign-on explains the identity-versus-permission split; Per-brand data isolation covers the boundary the grants enforce.

What is happening

Invites are issued by a console administrator through Triangle identity and accepted at the console's /invite page, which reads the token from the link's query string. Invite tokens are single-purpose credentials with their own signing discipline — they are short-lived and single-use by design.

Common causes

• The link was truncated. "Missing invite token" means the URL arrived without its query string — a chat client or mail forwarder clipped it. Copy the full link from the original message.
• The token expired or was already used. A used or stale invite cannot be re-opened; there is no refresh flow on the acceptance page.
• The invite was revoked and re-issued. Only the newest link works.

The fix

Ask the administrator who invited you to issue a fresh invite from the console's user administration. Accepting it signs you in through the same Triangle front door as every other operator — you do not need a separate account anywhere.

What is happening

Every console read is evaluated against your resolved scope: the brands and paths your grants cover. Isolation is enforced at the database level, and scope resolution fails closed — when your permissions cannot be resolved you see nothing rather than everything. Missing data is usually the boundary holding, not the record missing.

Check, in order

1. Confirm the brand context. Console views are scoped per brand; a record under a sibling brand is invisible here by design.
2. Confirm your grants cover this surface. Read access and manage access are separate grants.
3. Sign in fresh. A session mid-rotation can resolve a narrower scope than you expect; a clean sign-in re-resolves it.

When it is genuinely wrong

If a record you could see yesterday is gone under the same brand and grants, that is a real incident — capture what changed and when, and open a ticket with the product area set to the affected console surface.

RLS isolation mechanics and Per-brand data isolation describe the boundary you are seeing.

What is happening

Outbound webhooks are delivered at-least-once: the platform retries a failing delivery with exponential backoff up to an attempt ceiling, then moves it to a dead-letter queue where operators can inspect and replay it. "Stopped" almost always means your endpoint stopped acknowledging and deliveries exhausted their retries — nothing is silently dropped.

Check, in order

1. Is the endpoint answering? A 2xx response is the acknowledgement; timeouts and 5xx count as failures.
2. Did signature verification start rejecting? Verify over the raw request body bytes, never a re-serialized payload, and check the timestamp — receivers must reject messages outside the replay window (five minutes by default). A framework middleware that parses the body before your verifier runs is the classic break.
3. Is your handler idempotent? At-least-once means duplicates arrive; a handler that errors on a duplicate delivery fails the acknowledgement and triggers retries.

Recovery

Dead-lettered deliveries can be inspected and replayed — a replay service exists for exactly this. Credentialed operators do this in the console; if you cannot reach it, open a ticket with the product area set to integrations.

Webhooks & the event substrate documents the outbox, retry policy, and signature format.

What is promised

Published HTTP and event contracts change additively: new fields may appear, existing ones are not removed or retyped within a version. A client written against a contract should not have the type changed underneath it.

What usually actually broke

• Strict payload parsing. A decoder that rejects unknown fields breaks on a legal additive change. Tolerate fields you do not consume.
• Undocumented surface. Internal routes — anything outside the published API reference — carry no compatibility promise.
• Version drift. Check which contract version your client pins against the API reference before assuming the platform moved.

If you verified all three and a published contract still changed non-additively, that is a defect: open a ticket with the endpoint, the payload shape you expected, and what arrived.

API versioning & compatibility states the full policy.

The short answer

The public status page publishes qualitative health notes only — no uptime percentages, no per-service indicators. A public number the team cannot keep truthful in real time does not get published.

Where live health actually lives

Live, per-deployment health is a console surface for credentialed operators — it carries the context a public page never has: your brand, your deployment, your environment. If you operate a deployment and need current health, the console is the surface built for it.

During an incident

The public page routes and orients; the authenticated incident record is authoritative. Public updates state observed impact without guessing at cause, separate confirmed facts from active investigation, and close the loop only after the affected workflow is verified — not merely restarted.

Support and incident readiness covers the operating posture behind these rules.

How it is supposed to work

This site reads prefers-reduced-motion: reduce from your operating system, live. When it is set: scroll-cinema and animated sequences fall back to static layouts, and every live WebGL surface (heroes, dock scenes) renders its static poster instead. The preference is read from the OS — there is no separate on-site toggle.

Verify the setting first

• macOS: System Settings → Accessibility → Display → Reduce motion.
• Windows: Settings → Accessibility → Visual effects → Animation effects, off.
• Android: Settings → Accessibility → Remove animations.
• iOS: Settings → Accessibility → Motion → Reduce Motion.

The change applies live — no reload should be needed, though a reload rules out a stale tab.

If the setting is on and motion still plays

That is a defect, not a polish gap: shipping a motion experience without a reduced-motion path violates this site's own rules. Open a ticket with the product area set to "marketing site", name the page, and include your OS and browser.

The path

The form below posts to this site's /api/intake route, which forwards your submission to the console's intake endpoint. Valid submissions land in the staff Inquiries inbox with status "new" and return a reference id — keep it if you want to follow up.

What the desks mean

Every submission carries a desk — operations, partnerships, capital, trust, careers, or general — so it routes to the people who own that area. Support tickets from this page go to the general desk, tagged as support tickets, with your product area and severity attached.

What you will not get

No autoresponder theater, no ticket-queue bot. A person reads every submission. We respond within 1 business day during pilot phase.

If you are a bot

The form carries a honeypot field and a minimum-fill-time check. Trapped submissions receive the same success shape as real ones — but nothing is persisted and nobody will ever see them.