Reporting Issues
import { Aside } from ‘@astrojs/starlight/components’;
This guide walks you through filing a useful support ticket, what kind of ticket to file when, and what the lifecycle looks like from your end.
For a field-by-field reference of the form itself, see Report an Issue (UI).
When to file a ticket
Section titled “When to file a ticket”If you’re inside the portal, the answer is almost always “now, while you can still see it”. The form auto-captures your recent activity, current page, and browser, so the closer to the problem you submit, the more useful the context.
For things that aren’t tied to the portal — emergency security disclosures, account-level questions — use the same form. We route tickets to the right team based on the type and description you provide.
Choosing the right type
Section titled “Choosing the right type”┌────────────────────────────────────────────────────────────┐│ ││ Did something genuinely break? ││ - 500 error, white screen, button does nothing ││ - Event/log disappeared or showed wrong data ││ - Schedule fired at the wrong time ││ │ yes ││ ▼ ││ ┌──────┐ ││ │ Bug │ ││ └──────┘ ││ ││ Is the behaviour 'working' but wrong/slow/confusing? ││ - UX friction, missing feature, slow page load ││ - Documentation gap, suggestion ││ │ yes ││ ▼ ││ ┌──────┐ ││ │ Issue│ ││ └──────┘ ││ ││ Are you unsure if what you're seeing is correct? ││ - "Is this how it's supposed to work?" ││ - "Where do I configure X?" ││ │ yes ││ ▼ ││ ┌─────────┐ ││ │Question │ ││ └─────────┘ ││ │└────────────────────────────────────────────────────────────┘If in doubt, pick the type that feels closest. We triage from your description anyway.
Writing the description
Section titled “Writing the description”A good description has four parts:
1. What you did → "I went to /events, filtered by event type 'cron.hourly', and clicked the first row to open the detail panel."
2. What you expected → "The Logs section should show the latest run."
3. What happened instead → "The panel loads but the Logs section is empty. Refreshing shows the same thing. The Events list shows the run was successful with a log_url set."
4. When / how often → "Started after the migration last Tuesday. Happens on every cron.hourly event, but cron.daily events are fine."We almost always have the technical context already (your tenant, recent events, browser). What we need from you is what you were trying to do and what surprised you.
Screenshots
Section titled “Screenshots”Drag-and-drop or click Add screenshots. Useful captures:
| Good screenshot | Why |
|---|---|
| The whole portal window | Shows context — which page, which filters |
| The browser DevTools network tab | Shows the failing request |
| The browser console | Shows JS errors |
| A diff of “before vs after” if the same view changed | Shows regression |
Avoid:
- Screenshots of secrets pages or values. They’re already redacted in the UI, but skip them anyway.
- Photos of your screen with your phone. Use the built-in screenshot tool — much clearer and smaller.
- Animated GIFs > 5 MB. The system rejects them; a 30-second screen recording converted to a still-frame sequence is almost always enough.
Limits: 5 files, 5 MB each, 15 MB total. PNG/JPEG/WebP/GIF only.
The lifecycle
Section titled “The lifecycle”After you submit:
You click Submit │ ▼ You see SUP-XXXXXXXX on screen │ ▼ 📧 Email — "We received your report" │ (within seconds) ▼ [Our team triages] │ ▼ 📧 Email — "We started working on SUP-XXXXXXXX" │ (status: In Progress) ▼ [Engineering investigates / fixes] │ ▼ 📧 Email — "SUP-XXXXXXXX is resolved" │ (status: Done / Resolved / Closed) │ Includes a message from our team if one was left ▼ Done. If you have follow-up questions, reply to that email or submit a new report referencing SUP-XXXXXXXX.We email on status transitions only — we don’t spam you with internal back-and-forth chatter. When your ticket is resolved or closed, the email includes the latest note our team left — so you know what was fixed or what to do next.
Rate limit
Section titled “Rate limit”5 tickets per tenant per hour. The form tells you when you can submit again if you hit the limit.
If you genuinely have 10 separate issues, batch them in a single ticket with a numbered list:
- Login redirect doesn’t honour ?next=… param
- Event detail page shows raw JSON for results
- …
That’s much easier for us to triage than 10 separate tickets.
Following up
Section titled “Following up”The confirmation email is from noreply@…, but if you reply, your
message is added to our internal ticket. Quote the SUP-…
reference in the subject line so we can match it up — it should
already be there, but doesn’t hurt to double-check.
For new but related issues after the ticket is closed, file a new
report and mention the original SUP-… in the description.
If the system can’t file your report
Section titled “If the system can’t file your report”In rare cases (e.g. an outage on our side) we may not be able to automatically file your report. If that happens you’ll get an email saying so — your report is not lost, our team has been paged and we’ll reach out directly with next steps.