Debugging and Monitoring with the Service Studio Debugger and Service Center

Quick Answer: The Service Studio debugger lets you set breakpoints in action flows, step through logic (Step Into, Step Over, Step Out), and inspect variable values during a live session. Breakpoints only work when the module is published in Debug mode — Release mode omits debug symbols. In reactive apps, you can debug both client-side Client Actions and server-side Server Actions. Service Center is the web console for runtime monitoring, error logs, module management, and Site Property configuration.

The Service Studio Debugger

The Service Studio debugger is the primary tool for stepping through action logic at runtime. It lets you set breakpoints in Server Actions, Client Actions, Data Actions, and screen event handlers. When the running application hits a breakpoint, execution pauses and the Debug perspective opens, showing the current node, the call stack, and all in-scope variable values.

Debugger capabilities:

To start debugging, publish the module in Debug mode (the default during development), then start the debugger from the Debug menu. The debugger attaches to the running session. When a breakpoint is hit, the Debug perspective shows the paused execution point and lets you inspect or modify variable values before continuing.

Debug vs Release Publish Mode

A critical exam point: breakpoints are only honored when the module is published in Debug mode. When you publish in Release mode, the platform optimizes the generated code and omits debug symbols, so the debugger cannot pause at breakpoints. If your breakpoints are not being hit, the first troubleshooting step is to verify the module is published in Debug mode and republish if necessary.

Use Debug mode for active development and testing. Switch to Release mode for production deployment or performance measurement without debugger overhead.

Debugging Reactive Client vs Server Logic

Reactive Web Apps execute logic in two contexts: the browser and the server. The debugger handles both, but the context matters for what you can inspect:

• Client Actions run in the browser. When a breakpoint in a Client Action is hit, the debugger pauses browser-side execution and shows client-side variables (Local Variables, Client Variables, input parameters). The Debug perspective connects to the client session.
• Server Actions run on the server. When a breakpoint in a Server Action is hit, the debugger pauses server-side execution and shows server-side variables (input/output parameters, Session Variables, Local Variables). Server-side debugging requires the debugger connected to the correct environment.
• Data Actions run server-side to fetch data. Breakpoints in a Data Action's logic pause server-side execution, letting you inspect the fetch parameters and query results before they return to the client.

When debugging a flow that crosses the client-server boundary (a Client Action calls a Server Action), the debugger follows execution across the boundary — you can step from the Client Action into the Server Action, inspecting variables in both contexts.

Service Center: Runtime Monitoring

Service Center is the web-based operations console for each OutSystems server environment, accessed at /ServiceCenter on the environment URL. It provides:

• Error Logs: Searchable runtime exceptions with stack traces, timestamps, and the module/action where the error occurred. The first place to look when troubleshooting a production issue.
• General Logs: All logged messages, including custom LogMessage calls and system events, filterable by module, action, and time range.
• Module Management: View installed modules and their versions, publish or unpublish modules.
• Site Properties: View and override runtime values of Site Properties without republishing.
• Performance Monitoring: Request timing, slow query identification, and environment health metrics.

Service Center is environment-specific — each environment (Development, Test, Production) has its own instance. LifeTime, by contrast, is the cross-environment deployment console for promoting modules between environments and tagging versions.

Troubleshooting Patterns

Common debugging and monitoring patterns tested on the exam:

1. Breakpoints not hitting: Verify the module is published in Debug mode. Release mode omits debug symbols, so breakpoints are ignored. Republish in Debug mode and retry.
2. Runtime error in production: Open Service Center Error logs, search by module name or time range, read the stack trace to identify the failing action and exception message. Common causes include null references, type mismatches, and unhandled exceptions in Server Actions.
3. Data not refreshing after parameter change: If a screen's Data Action does not update when input parameters change, verify that OnParametersChanged includes a RefreshData call for the Data Action.
4. Client Variable appearing stale: Client Variables are per-browser-session and do not sync across tabs or devices. Check whether the variable was set in a different browser session.
5. Site Property change not taking effect: Verify the runtime value in Service Center persisted and that consuming logic reads the current value. Server Actions read Site Property values at execution time.

When debugging, combine breakpoints with variable inspection to verify that assumptions about data values match reality. A frequent finding is that an input parameter or Local Variable has an unexpected null or default value, causing downstream logic to fail. Setting a breakpoint early in the flow and inspecting all variables is the fastest way to localize the issue.