You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This sample covered 2 workflow runs from the last 7 days. Observability is complete for the components that were enabled: the single firewall-enabled run has a populated Squid access.log, and both MCP-enabled runs have canonical RPC telemetry (rpc-messages.jsonl). No missing critical telemetry was found.
The only quality note is that the firewall log is mostly transaction-end-before-headers errors rather than explicit deny lines, so it is more useful for connection tracing than for proving blocked egress behavior.
Key Alerts and Anomalies
No critical issues detected.
Coverage Summary
Component
Runs Analyzed
Logs Present
Coverage
Status
AWF Firewall (access.log)
1
1
100%
✅
MCP Gateway (gateway.jsonl or rpc-messages.jsonl)
2
2
100%
✅
📋 Detailed Run Analysis
Firewall-Enabled Runs
Workflow
Run ID
access.log
Entries
Allowed
Blocked/Errors
Status
PR Sous Chef
29214279165
✅
122
56
66
✅
Missing Firewall Logs (access.log)
None.
MCP-Enabled Runs
Workflow
Run ID
Telemetry Source
Entries
Servers
Tool Calls
Errors
Status
PR Sous Chef
29214279165
rpc-messages.jsonl
12
safeoutputs
5
0
✅
Smoke CI
29206909973
rpc-messages.jsonl
6
github, safeoutputs
0
0
✅
Missing MCP Telemetry
None.
🔍 Telemetry Quality Analysis
workflow_runs_analyzed: 2
firewall_enabled_workflows: 1
mcp_enabled_workflows: 2
Firewall log quality: 122 entries, 3 external hosts, 56 allowed connects, 66 local error/abort records.
MCP log quality: 18 RPC entries total across both sampled runs, valid JSONL, no parse errors.
Healthy runs summary: both sampled runs have the telemetry needed for debugging their enabled components.
Recommended Actions
Keep attaching Squid access.log artifacts on every firewall-enabled run.
Preserve rpc-messages.jsonl fallback until gateway.jsonl coverage is universal.
If you want stronger negative-path evidence, add a run that exercises explicit blocked egress so deny traces are visible in the firewall log.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Caution
agentic threat detected
Threat detection flagged this output in warn mode. Manual review is REQUIRED before any follow-up automation.
Details
The threat detection engine failed to produce results.
Review the workflow run logs for details.
Executive Summary
This sample covered 2 workflow runs from the last 7 days. Observability is complete for the components that were enabled: the single firewall-enabled run has a populated Squid
access.log, and both MCP-enabled runs have canonical RPC telemetry (rpc-messages.jsonl). No missing critical telemetry was found.The only quality note is that the firewall log is mostly
transaction-end-before-headerserrors rather than explicit deny lines, so it is more useful for connection tracing than for proving blocked egress behavior.Key Alerts and Anomalies
No critical issues detected.
Coverage Summary
📋 Detailed Run Analysis
Firewall-Enabled Runs
Missing Firewall Logs (access.log)
None.
MCP-Enabled Runs
Missing MCP Telemetry
None.
🔍 Telemetry Quality Analysis
workflow_runs_analyzed: 2firewall_enabled_workflows: 1mcp_enabled_workflows: 2Recommended Actions
access.logartifacts on every firewall-enabled run.rpc-messages.jsonlfallback untilgateway.jsonlcoverage is universal.References:
Report generated automatically by the Daily Observability Report workflow
Analysis window: Last 7 days | Runs analyzed: 2
Beta Was this translation helpful? Give feedback.
All reactions