Executive Summary
No token consumption telemetry could be retrieved for 2026-05-05 (last 24 hours). This is the 6th+ consecutive day this workflow has been blocked by the same two infrastructure gaps: the Sentry token lacks organization-level read permissions (HTTP 403), and the search_events span-query tool is not present in the mounted Sentry MCP server.
The local OTel file (/tmp/gh-aw/otel.jsonl) contains exactly 1 span — the setup span for the current workflow run — carrying no token-usage attributes.
Key Metrics
| Metric |
Value |
| Events analyzed |
1 (current run setup span only) |
| Events with token data |
0 |
| Total input tokens |
N/A |
| Total output tokens |
N/A |
| Total tokens |
N/A |
| Unique workflows |
N/A |
| Avg tokens/event |
N/A |
| P95 tokens/event |
N/A |
Top 10 Workflows by Token Consumption
No data available — Sentry telemetry could not be queried.
Data Quality and Gaps
Errors Encountered
| Call |
Result |
find_organizations |
HTTP 403 — no permission to list organizations |
find_projects(organizationSlug: "github") |
HTTP 403 |
search_events |
Tool not present in mounted MCP server |
What Was Available
- Authenticated user:
jhalleux@microsoft.com (Peli de Halleux, Sentry user ID 4401625) — authenticated but lacking org-level read permissions.
- Local OTel file:
/tmp/gh-aw/otel.jsonl — 1 span (gh-aw.agent.setup, run 25375562206). No token fields (ai.input_tokens, ai.output_tokens, etc.) present.
- MCP tools mounted:
whoami, find_organizations, find_projects, find_releases, find_teams, find_dsns, search_docs, get_doc, get_event_attachment, analyze_issue_with_seer. Missing: search_events, get_issue_details, get_trace_details, search_issues.
Recurrence Pattern
This blocker has persisted across at least these runs:
Assumptions and Fallbacks
None applied — no token fields were found in any available data source. Values reported as N/A are genuinely absent, not zeroed.
Recommendations
-
Fix Sentry token permissions (highest priority): The SENTRY_ACCESS_TOKEN secret needs the scopes org:read and project:read for the github organization. Rotate or update the token in repository secrets. This single fix would unblock data collection.
-
Add search_events to the mounted MCP server: The shared sentry.md MCP config lists search_events as allowed, but it is not exposed in the running server. Verify the @sentry/mcp-server@0.33.0 version correctly exposes this tool and that no allow-list filtering strips it at mount time.
-
Emit token telemetry locally: As a resilient fallback, configure the gh-aw harness to append token usage from each workflow turn to /tmp/gh-aw/otel.jsonl using a gh-aw.token_usage span convention. This decouples the report from Sentry availability.
-
Add a pre-flight check: Insert a setup step that validates Sentry connectivity (whoami + find_organizations) and surfaces a clear error before the agent wastes a full run on an unrecoverable blocker.
References
Generated by Daily Token Consumption Report (Sentry OTel) · ● 231.8K · ◷
Executive Summary
No token consumption telemetry could be retrieved for 2026-05-05 (last 24 hours). This is the 6th+ consecutive day this workflow has been blocked by the same two infrastructure gaps: the Sentry token lacks organization-level read permissions (HTTP 403), and the
search_eventsspan-query tool is not present in the mounted Sentry MCP server.The local OTel file (
/tmp/gh-aw/otel.jsonl) contains exactly 1 span — the setup span for the current workflow run — carrying no token-usage attributes.Key Metrics
Top 10 Workflows by Token Consumption
No data available — Sentry telemetry could not be queried.
Data Quality and Gaps
Errors Encountered
find_organizationsfind_projects(organizationSlug: "github")search_eventsWhat Was Available
jhalleux@microsoft.com(Peli de Halleux, Sentry user ID 4401625) — authenticated but lacking org-level read permissions./tmp/gh-aw/otel.jsonl— 1 span (gh-aw.agent.setup, run25375562206). No token fields (ai.input_tokens,ai.output_tokens, etc.) present.whoami,find_organizations,find_projects,find_releases,find_teams,find_dsns,search_docs,get_doc,get_event_attachment,analyze_issue_with_seer. Missing:search_events,get_issue_details,get_trace_details,search_issues.Recurrence Pattern
This blocker has persisted across at least these runs:
Assumptions and Fallbacks
None applied — no token fields were found in any available data source. Values reported as N/A are genuinely absent, not zeroed.
Recommendations
Fix Sentry token permissions (highest priority): The
SENTRY_ACCESS_TOKENsecret needs the scopesorg:readandproject:readfor thegithuborganization. Rotate or update the token in repository secrets. This single fix would unblock data collection.Add
search_eventsto the mounted MCP server: The sharedsentry.mdMCP config listssearch_eventsas allowed, but it is not exposed in the running server. Verify the@sentry/mcp-server@0.33.0version correctly exposes this tool and that no allow-list filtering strips it at mount time.Emit token telemetry locally: As a resilient fallback, configure the gh-aw harness to append token usage from each workflow turn to
/tmp/gh-aw/otel.jsonlusing agh-aw.token_usagespan convention. This decouples the report from Sentry availability.Add a pre-flight check: Insert a setup step that validates Sentry connectivity (
whoami+find_organizations) and surfaces a clear error before the agent wastes a full run on an unrecoverable blocker.References