Debugging workflows
Follow failures and log context back to code
Use the request status and findings to find the relevant exception, then inspect application frames, retained causes, source context, and nearby log entries.
Start with the selected request
Confirm the method, path, request type, and time. A failed background request can appear after a successful page response, and an exception may be reported even when application code catches it and returns a normal status.
Open the exception summary
Use the exception class, message, occurrence count, and first application location to choose the failure that matches the symptom. Repeated reports of the same logical exception stay grouped so one cause does not dominate the view.
Open the detail for its application path and source context. Framework frames remain available for deeper tracing, but begin where your application first enters the failing path.
Read retained causes and frames
Wrapped exceptions can preserve a chain of causes. Follow the chain until the message and location explain the original failure, then move outward to see how application code handled or transformed it.
- Application frames show the code path you control.
- Vendor frames show framework or package behavior when deeper context is needed.
- Source context keeps the failing line with nearby code within the configured limit.
- Related logs, queries, HTTP calls, and timeline items can explain what happened immediately before the failure.
Use logs as request-scoped context
The Logs section keeps level, message, bounded context, channel information, and the application source that wrote each retained entry. Because the entries belong to one profile, you do not need to search a large log file by time alone.
Start with warning and error levels, but keep lower-level entries when they record the state transition or external identifier that explains the failure. Common sensitive keys are redacted during capture.
Use one evidence loop
-
Reproduce one failing action
Capture the exact request and note its profile ID. -
Open the first application failure
Read the message, causes, application frame, and source context. -
Check nearby evidence
Use the timeline and related logs, queries, or HTTP calls to test the likely cause. -
Repeat after the change
Confirm the request behavior and all error findings, not only the original message.
Next step
Protect an error-free path
Use a stored response profile in Pest to assert that an important request has no error response or exception finding.
Open the testing guide