Filing a support case

You can report a problem without leaving ARDS. Use it for anything where email feels heavy — bug reports, "is this expected?" questions, feature requests.

Filing a case

Click the floating ? button in the bottom-right corner (Help & support). It offers two options: Ask the assistant, for product questions, and Report an issue, which opens the report form:

  • Summary — one short line. "Mission stuck Decomposing for 3 minutes" is good. "It's broken" isn't.
  • Description — what happened, what you expected, what you tried. Include rough timestamps (so we can find logs).
  • Severity (optional) — Low / Medium / High. Leave it empty if you're not sure; we triage everything anyway.
  • Include a screenshot of the current page — tick it and ARDS captures the page for you when you submit.
  • Attachments (optional) — add files from disk: up to 20 per report, 10 MB total. For anything bigger, use email.

Click Submit. The case appears on your Support cases page in state Received.

Why use this over email

Cases filed in-app are tied to your tenant, can carry a screenshot of the exact page where things went wrong, and surface in your dashboard — you see every status change directly, without checking your inbox.

Email still works (see Getting help — support@etiakorp.com). Use email when:

  • You can't sign in (so you can't open a case).
  • Your files exceed the in-app limit (20 attachments / 10 MB per report).
  • The issue involves billing or security and you'd rather not file it in-band.

What happens next

We read it. Response times during early access are best-effort — somewhere between minutes and a couple of business days depending on time zone and severity.

The case moves through states you'll see as badges:

  • Received — filed, not yet picked up.
  • Investigating — someone (or an investigation mission) is looking at it.
  • AwaitingReporter — we asked a question; the case thread says "The team is waiting on your reply." — answer there.
  • Confirmed / Fixing — the bug is reproduced, then being fixed.
  • AwaitingVerification — a fix shipped, and it's your call: "The team has shipped a fix. Please verify whether it resolves your issue." with two buttons, Confirm fixed and Still broken. Only you, the reporter, can close this loop.
  • Resolved — you confirmed the fix.

A case can also close with a verdict instead of a fix: WontFix, CannotReproduce, Misconfiguration, Misuse, or Duplicate — each states why, so the outcome is never a silent close.

While a case is open you can add context to the thread at any time; it doesn't change the state.

Anti-patterns

  • Don't paste secrets. Mask anything sensitive in screenshots. We don't need API keys or tokens to diagnose — they make our retention story harder.
  • Don't file the same issue twice. If you see the same bug a second time, add a message to the existing case. Multiple cases for one bug make us slower to triage.
  • Don't inflate severity on feature requests. It dilutes the signal. Leave severity empty or Low; we read everything.

Status check

Your Support cases page lists all your tenant's cases, filterable by project and status. Each row shows the case's state, its severity hint, and an SLA badge — On track, Stale, or Overdue — so you can see at a glance whether it's moving. Opening a case shows its full thread, attachments, and any investigation missions ARDS spawned for it.