OutSystems provides strong local debugging (breakpoints, step‑through execution) and logs, and in ODC it already supports distributed traces at a technical level. However, from a developer’s point of view, there is still a significant gap between raw observability data and actionable troubleshooting.

I’m proposing a developer‑centric, end‑to‑end request trace experience that makes it easy to understand what happened for a single user action: from the UI event, through server logic, to database operations and external integrations, without manual correlation.

Service Studio debugging works well within a module, but once a request crosses: 

• UI → Server Actions 
• Aggregates → Integrations 
• Async flows / Timers 

developers must manually jump between: 

• Debugger Logs 
• Integration error screens 
• External system logs 

This fragmentation slows down root‑cause analysis and increases support effort, especially for intermittent or environment‑specific issues.

Logs show facts / data, but not context.

Logs record events, but:

• Developers must manually infer which UI action triggered which server/integration call 
• Correlating logs across layers requires custom correlation IDs or naming conventions 
• Performance issues often require guesswork to identify the slow component 

Traces technically capture request lifecycles, but developers don’t yet have a single, intuitive “story view” of a request that ties everything together in a one‑click request trace view that: 

• Starts from a user action (e.g., button click, screen load) 
• Shows the full execution chain across: 
  • UI action Server actions 
  • Aggregates / queries 
  • Integration calls 
  • Async operations (where applicable) 
• Presents timing, failures, and context in a single timeline 

This is not about adding more logs, but about connecting existing observability data into a developer‑friendly narrative.