Troubleshoot Real-Time Events

This page lists the symptoms a Real-Time Events search shows, each with its cause and its fix. Four classes of symptom are covered: a search that returns no record, a query a limit refused, an endpoint that answers nothing, and a field a dataset does not carry. Every fix on this page changes the query, never the configuration of the product that wrote the records.

A query returns no record for an event that just happened

A search covering a request you sent moments ago comes back with no record, although the request was served.

Real-Time Events makes a record queryable up to 30 seconds after the event that produced it, rather than at the instant of it. A search that runs immediately therefore reads a period the record has not landed in yet.

• Run the same search again: the record appears once it is queryable, with no change to the query.
• Set the end of the period to the current moment: a range that closed before the request was served never covers it.
• Confirm a record exists at all: a product that handled no work writes none, as How Real-Time Events works explains.
• Wait out the delay before concluding anything: refer to Limits for this bound alongside every other one.

The search then returns the record, carrying every variable its data source defines.

The endpoint answers 204 with an empty body

A query to the Real-Time Events GraphQL API answers with HTTP status 204 and no body at all, carrying neither data nor an error.

The request reached https://api.azion.com/events/graphql, the path without /v4. That path answers 204 with an empty body for every request it receives, so a correct query sent there is indistinguishable from a search that matched nothing.

• Send the query to https://api.azion.com/v4/events/graphql: this is the path the Real-Time Events GraphQL API answers on.
• Read the status line before the body: a 204 carries no message, so a client that inspects only the body reports an empty result and hides the cause.
• Fix the path everywhere it is stored: a saved client, a script, and an integration each keep their own copy of the URL.

The v4 path answers with a JSON body, holding either the records the query selected or an error that names what is wrong with it.

A query is refused with A query limit was exceeded

A search fails and returns A query limit was exceeded. Try to refine your filter parameters or query a smaller period for a more precise search.

The log database bounds how many rows one query may read before it answers, and it counts the rows read rather than the rows returned. A search over a broad period with no other filter reads every row in that period, so it reaches the bound while returning almost nothing.

• Add one filter: a host, an IP address, an HTTP status code, or another parameter of the search cuts the read down before the period has to.
• Shorten the period: a narrower range reads fewer rows, although a filter changes the outcome more than the period does.
• Ask several narrow questions: two filtered searches return what one unfiltered search is refused for.
• Request a higher bound: Azion raises a default limit based on your plan, through technical support.

The query then returns its rows instead of the error. For the bound this message reports, refer to Limits.

A query returns no record for an older event

A search over a period weeks or months back returns nothing, while the same search over a recent period returns records.

Real-Time Events keeps an event record for 7 days and then removes it, and nothing recovers a record once it is gone. A period reaching further back than retention returns nothing for the part that falls outside the window, because there is nothing left there to read.

• Query inside the retention window: Limits carries the period each data source keeps its records for.
• Query Activity History for an action on the account: that data source keeps its records for 2 years, far longer than the other seven, as Data sources records.
• Send the records to a store of your own before they are removed: Data Stream delivers the same records continuously to an endpoint you control, where your own retention applies.

A search inside the window returns its records, and a question about an older event is answered by the store the records were sent to.

A field is rejected or returns no value

A query fails on a field name, or it runs and that field comes back empty on every record.

Azion Console names a field as a variable and the Real-Time Events GraphQL API names the same field in camelCase, so the variable Remote Address is the field remoteAddress. A field also belongs to one dataset, so a name taken from another dataset is not a field of the one the query reads.

• Take the spelling from the dataset’s own field list: Real-Time Events GraphQL API fields gives the field name and the type each dataset accepts.
• Do not reuse a Data Stream spelling: a Data Stream payload writes the same field in snake_case, which a GraphQL query does not accept.
• Confirm the field belongs to the data source you selected: Data sources names each data source’s dataset beside its variables.

The query then parses, and the field returns a value on every record that carries one.

A query is refused for selecting too many fields or asking for too many rows

A query is refused with an error response that names a limit on the fields it selected or on the rows it asked for.

The GraphQL API bounds both the number of fields one query selects and the number of rows one query returns. Both bounds belong to the API itself and apply to every dataset it serves, so no choice of data source avoids them.

• Select fewer fields: ask for the fields the question needs, and read the rest in a second query over the same period.
• Lower limit: the limit field sets how many rows a query returns, and a smaller value keeps the query inside the row bound.
• Read the body the error carries: refer to GraphQL API error responses.

A query inside both bounds returns its rows. For the two values, refer to Limits and GraphQL API limits.

Related resources