Customer log timeline for support agents, without Kibana

Build me an app my support agents open whenever a customer reports that something broke, so they stop pasting query syntax into Kibana or interrupting an engineer for every lookup. It reads log and event data from Elasticsearch and works alongside our Zendesk tickets.

The main surface is a single lookup box. An agent types one identifier, either a customer email, an account ID, or an order ID, and the app uses the Elasticsearch Search Documents (Query Index) operation against the configured log and event indices and renders the matches as a readable timeline ordered by timestamp, newest first. Rows whose level or status marks them as a failure are visually highlighted as errors. Every row is expandable to reveal the raw document underneath, so an engineer looking over an agent's shoulder can still see ground truth, but the collapsed row shows only a human-readable summary: when it happened, what happened, and which part of the system it came from.

Down the side, give the timeline filters for time range, environment, and log source. The time range defaults to the last 24 hours, with one-click toggles for 7 days and 30 days. Environment and log source are dropdowns. Populate the log source dropdown using the Elasticsearch List Indices operation, filtered to the indices an admin allowed in settings, rather than making anyone type an index name.

Across the top, show a header strip driven by the Elasticsearch Count Documents operation: how many error events versus how many normal events that customer hit in the selected window. Two counts, stated plainly, so the agent immediately knows whether this customer had a bad time or a normal one. Important: hits.total caps at 10,000 by default, so pass track_total_hits when the counts need to be exact, otherwise a busy customer's numbers will silently flatten at 10,000 and the strip will lie.

A second panel lists that customer's recent Zendesk tickets using the Search Tickets operation, matched on the same identifier the agent typed. Selecting a ticket loads its full thread with the List Ticket Comments operation, showing public replies and internal notes in order. The point is that the agent reads the customer's complaint in their own words directly next to the evidence of what actually happened, without switching tabs.

Every timeline row has an Attach to ticket action, and agents can also multi-select several rows and attach them together. Attaching writes the chosen entries into the selected Zendesk ticket as an internal note using the Update Ticket operation, formatted readably with timestamps and messages rather than as a dump of raw JSON. This is always an internal note, never a public reply, because it is evidence for the team and not something the customer should receive.

Add an Explain what happened button that kicks off a background agent. It reads the log documents currently matched for this customer, identifies the dominant error signature among them, then runs follow-up Search Documents calls for that same signature across all customers over the same period to judge whether the problem is isolated to this one customer or widespread. It writes back into the app a plain-language explanation of what went wrong, in language a non-engineer can repeat to a customer, plus a blast-radius count of how many other customers hit the same error. Its output lands in the app for the support agent to read and approve. The agent must never post anything to Zendesk or to the customer by itself; a human decides whether any of it gets used.

Include a small settings screen for an admin. The identifier field must be configurable, because every cluster names it differently and the app is useless if it guesses wrong: common values are user.email, account_id, and customer.id. Use the Elasticsearch Get Index Schema (Mapping and Settings) operation to offer the real field names from the selected index as choices instead of making an admin type a field path blind. Settings also cover which indices agents may search, which field carries the environment, and which values count as an error. Settings are shared across the whole team, not per agent, so everyone searches the same way.

Two hard rules on the agent-facing UI. First, it must never show raw Query DSL anywhere, not in a preview, not in an advanced panel, not in an error message. If a search fails, say so in plain language. Second, use support vocabulary rather than Elasticsearch vocabulary throughout: say log source rather than index, say entry or event rather than document, say time range rather than range query. The people using this all day should never need to learn what an index is.

One connection note: Elasticsearch is authenticated per cluster with a base URL supplied by the user alongside an encoded key, so never hard-code a host anywhere in the app. Always build requests from the configured base URL.