Support escalation

This is the page that, if followed, gets your issue triaged in one round-trip instead of three.

Before you open a ticket

Please run the two-minute checklist:

1. Status page — is there an incident for your region? See Status and incidents.
2. Dashboard health badges — is anything yellow or red? See Monitoring.
3. Troubleshooting tree — does your symptom match a leaf? See Troubleshooting.

If the answer to all three is "I've checked and the problem persists", proceed.

The escalation template

Copy this into your ticket. Filling all of it saves at least one back-and-forth.

Severity:           [P1 | P2 | P3 | P4]
Organization ID:    org_…
Project ID:         prj_…           (if applicable)
Index slug:         products        (if applicable)
Region:             eu | us | ru

Symptom (one sentence):

When did it start (UTC):

Is it constant or intermittent:

Sample request ID (from x-request-id header):

What the client sees (status code + body):

What you've already checked from troubleshooting docs:

What changed recently on your side (deploys, schema, key rotation):

A complete first message lets us look at the right logs immediately. An incomplete first message becomes a 24-hour ping-pong because we can't search for the right thing.

Severity choice

You set the severity at the top of the template. Be honest — we'll re-prioritize internally if needed, but choosing P1 for a P3 issue pushes a real P1 down our queue.

For enterprise customers with a TAM, P1 also pings your TAM directly.

Sample first messages

A good P1

Severity: P1 Org: org_acme_corp Index slug: products Region: eu Symptom: All searches against products returning 502 since 14:02 UTC. Constant. Sample request ID: 01HXY7K… at 14:03:11 UTC. Client sees: 502 (no JSON body, looks like edge timeout). Status page is green for EU. We did not deploy or change keys today. Webhooks delivery also failing (last success 14:01).

This will be acknowledged within minutes because (a) the severity matches a real outage, (b) we have a request ID to look up immediately, and (c) the reporter ruled out the obvious local cause.

A bad P1

URGENT search is broken pls fix

We can't tell which organization is affected, which region, which index, or whether "broken" is a 4xx, a 5xx, or "the order seems off". We will ask all of these and the clock starts over.

A good P3

Severity: P3 Org: org_acme_corp Index slug: blog Symptom: Synonym sneakers => trainers not applied to queries. Started after the reindex on 2026-05-10 at 09:14 UTC. Sample request ID: 01HXY9... at 09:30 UTC. Workaround: re-running searchIndex.applySynonyms brings it back briefly, then it drifts again within an hour. We've checked: synonym set is in synonymSets on the index settings; the audit log shows it.

This will get triaged into "engineer needs to look at it" because it's reproducible, the reporter has done their part, and the workaround/cycle is clearly described.

What we will (and won't) ask you for

We will ask for:

• More request IDs spanning a wider time window if intermittent.
• A HAR file if it's a browser-side issue.
• Whether you can reproduce on a fresh API key (rules out key-specific config drift).
• The output of a curl that reproduces the issue (with auth scrubbed).

We will not ask for:

• A redacted copy of your application source.
• Your customers' data.
• Direct database credentials. (If a problem genuinely requires this — which is rare — we discuss out-of-band with security.)

If you're asked for something on the "will not" list, please send the request to security@aacsearch.com instead of replying.

SLAs and response times

These are first-response SLAs. Resolution times depend on the issue and are not guaranteed by SLA on standard plans.

How to reach us

After the ticket is resolved

If we close a ticket and you don't think it's resolved, reply within 7 days and it reopens. After 7 days a follow-up should be a new ticket — link the old one.

For P1/P2 incidents that affected your service, you can request a private post-incident review separate from the public PIR. Email the TAM or security@aacsearch.com.

See also

• Troubleshooting — the decision tree to run first
• Status and incidents — what we already know
• Monitoring — observe the signals so you catch issues before tickets