Inspect runtime events

Runtime events show what reached LightNow Proxy during an AI client session. Use them after client posture and proxy health are known: events explain the request path, while local checks explain the current configuration.

What an event can prove

Question	Useful fields
Did the client reach LightNow?	Timestamp, MCP client, runner, profile, event type
Where was the request routed?	Server alias, server name, tool name, original tool name, resource URI
Did it succeed?	Status, error type, error message
Was it slow?	Duration, request and response sizes, response item count

LightNow stores allowlisted metadata such as argument keys and response shape. It does not store raw tool arguments, tool results, resource contents, authorization headers, or secret values in runtime events.

1. Confirm telemetry and reachability

Runtime events are emitted only when telemetry is enabled for LightNow Proxy. The local proxy config stores this as local_proxy.telemetry_enabled.

Check posture, telemetry, and health

lightnow config-status --client codex --json
grep -n "telemetry_enabled" ~/.lightnow/lightnow-proxy/codex.yaml
lightnow-proxy --config ~/.lightnow/lightnow-proxy/codex.yaml --health --json

If telemetry is disabled, local posture and health still work but new requests do not appear in Insights. If posture is not managed or health fails, fix that boundary before interpreting the event stream.

2. Reproduce one action

1. Open Insights in the LightNow app.
2. Select the Runtime Profile used by the failing client.
3. Choose a short window such as 15m and narrow the event type or status.
4. Trigger one client action.
5. Wait for the Insights refresh and open the newest matching event.

Insights refreshes every 10 seconds. A narrow reproduction is easier to correlate than a long session with several agents or tool calls.

3. Read the first useful signal

Observation	Interpretation	Next step
No matching event	The client did not reach this proxy/profile, telemetry is off, or the session still uses old config.	Return to config-status, restart the client, and verify the selected context.
list_tools succeeds	Proxy routing and upstream discovery worked.	Investigate client cache or display behavior.
call_tool fails	The request reached the selected server but execution failed.	Compare server alias, error type, timing, and current proxy health.
Events succeed but are slow	Routing works; latency is the problem.	Compare the event with the Insights latency breakdown for the same server and window.

Resource activity uses list_resources, list_resource_templates, and read_resource. Tool activity uses list_tools and call_tool.

Query the API when needed

Use the API for a small support excerpt or scripted diagnostic. The selected account must have access to the Personal or organization scope.

List recent tool-call errors

curl -sS -H "Authorization: Bearer $LIGHTNOW_TOKEN" "https://registry-api.lightnow.ai/v0.1/integrations/runtime-events?profile=default&event_type=call_tool&status=error&window=1h&limit=20" | jq '.events[] | {created_at, server_alias, original_tool_name, error_type, duration_ms, argument_keys}'

Supported filters are profile, event_type, status, client_name, mcp_client_name, runner_name, server_alias, tool_name, resource_uri, window, and limit. Windows are 15m, 1h, 6h, 24h, 7d, and 30d; limit accepts 1 through 100.

Share metadata, not credentials

A runtime event is designed to be safe evidence, but review error messages before sharing them. Never add tokens, headers, raw arguments, results, or secrets from another source to the ticket.

Close the investigation

Record the event timestamp, profile, client, server alias, event type, status, duration, and correlation identifier when present. Then send the fix to the owning boundary: client and proxy posture, runtime secrets and config, or the upstream MCP server itself.