Event Telemetry: see exactly where a customer request went wrong

Each step arrives as an event, in order: what the agent did, when it happened, and what came back, from your systems or ours. Your team pulls the events with the Giga CLI, as JSON, so a script can put them next to the logs and dashboards it already watches.

Find the step that failed

Example: an order update that never landed. A customer calls to change the shipping address on an order that ships tomorrow. Your agent confirms the new address and sends it to your order system. The system returns an error, and the agent tells the customer someone will follow up.

The transcript shows a polite conversation. The events show the step that failed: your order API returned HTTP 500 when the agent tried to save the address. Now you know the agent did its part, which team owns the fix, and that the address still needs changing before the order ships.

Ask Scout, the AI assistant in the Giga console, about a conversation or a time window, and it reads the same events for you. Developers can run giga logs list --conversation <ticket id> to read them in a terminal.

Know whose fix it is

• Separate agent problems from problems in your systems. When an order update fails, the api.request event shows what your endpoint returned, so you know which team should get the ticket.
• See which version was live. Events from a conversation carry the version of the agent that handled it, and publishing a new version is an event too, so you can tell whether a problem started with a change.
• See why a transfer didn’t connect. When a transfer fails, call.transfer says why: no number was set up for it, your transfer code rejected it, the destination didn’t take it, or the caller hung up first.
• Find the same failure in other conversations. Search for code that errored or requests that timed out. giga logs list --event api.request --level error --since 7d lists failed API requests from the past week, 100 at a time unless you raise --limit.
• See what no transcript shows. A customer’s STOP reply is dropped before it reaches your agent, and a call that fails during startup never reaches the agent at all. consent.changed and conversation.start_failed record them; a call that fails before Giga loads your agent’s settings has no event.

Events answer more than these five questions, and not only for calls: chats have them too, and so do messages on SMS, WhatsApp, Zendesk and LiveChat.

Ask about a whole day, not one call. On an outbound line, a connected call only means the line picked up, and voicemail picks up too. One query over a day of events counts the answered calls and how each call ended:

giga logs query 'sum by (team_id, event, reason) (count_over_time({service_name="customer-events"} | event=~"call.connected|conversation.ended" [24h]))' --instant

The answer shows how many answered calls the agent flagged as voicemail, and so at most how many of your dials reached a person.

What to know

Events record what happened, not what was said. With PII redaction on for the agent, an event keeps only its name and fields, and your code’s printed lines are withheld. Events never include secrets, credentials or transcripts. Delivery is best effort, so an event can be lost, for example when a process stops mid-run. You can read back up to 30 days of events.

Get started

Event Telemetry is available now in the Giga CLI. Next time your team can’t explain what happened to a customer request, pull its events and see where it stopped.

New to Giga? See a demo and bring a customer request you’d like to trace.