A client timeout does not guarantee a useful entry in the SQL Server error log. Attention events record a client request to cancel server work. Capture them with session and statement context, then investigate why the request was canceled and whether its transaction remained open.
Separate Client Cancellation From Server Errors
A client can cancel a request because of a timeout, a user action, or its own workflow decision. SQL Server receives an attention signal and stops the relevant work as appropriate. That does not require the server to produce a conventional error-log entry explaining an application timeout.
I check cancellation evidence when the application reports failure but normal error searches remain quiet. The attention event confirms the request was canceled. It does not prove that blocking, CPU, or storage caused the delay. Those explanations need evidence from the request and surrounding workload.
The event also does not replace the application log. Client-side timeout settings and user actions supply information SQL Server cannot infer from the cancellation alone. Keep timestamps and connection context aligned across the two sources. The server knows somebody pressed stop. It does not receive the entire conversation that led to the decision.
Correlate attention events with application requests before deciding whether the cancellation came from a timeout or a deliberate user action.
Create a Bounded Capture in a Test Environment
The following server-scoped session captures attention with SQL text, application name, and session identifier. Its event-file target uses a Windows path on the SQL Server host. Create the folder first and give the required service account write access. Choose an unused session name and a short capture window.
The file limits bound retained capture size, but they do not make an unrestricted session appropriate for indefinite collection. Add a reviewed application, database, or session filter for a production investigation. Query text can contain sensitive values, so retain only the context needed for the diagnosis.
I leave startup disabled for this temporary example. Start it immediately before reproducing the cancellation, then stop it after collecting the evidence. A diagnostic session needs cleanup and ownership. Keeping a broad event capture running because it once helped an investigation creates another operational responsibility that nobody necessarily agreed to maintain.
CREATE EVENT SESSION CancelCapture ON SERVER
ADD EVENT sqlserver.attention
(ACTION(sqlserver.sql_text,sqlserver.client_app_name,sqlserver.session_id))
ADD TARGET package0.event_file
(SET filename=N'C:\SqlEvents\CancelCapture.xel',max_file_size=20,max_rollover_files=2)
WITH(STARTUP_STATE=OFF);
ALTER EVENT SESSION CancelCapture ON SERVER STATE=START;
Reproduce One Cancellation and Retain Its Route
Use a dedicated SSMS test connection and record its session identifier before the reproduction. Configure a finite execution timeout for that test connection or cancel the controlled request manually. The WAITFOR statement below supplies harmless work that lasts beyond the chosen test timeout.
The delay is an explicit demonstration setting, not a measured performance result. Do not use a real business update merely to trigger the event. A transaction-free wait makes the first experiment easier to clean up and separates event capture from transaction handling.
What cancellation path are you testing: a timeout or a deliberate stop? Record that answer. The same attention event can represent either path, so the event alone cannot distinguish them reliably. Match the session and application evidence with the test action. After the test, restore the connection's normal timeout setting so later diagnostic work does not inherit an unexpectedly short limit.
SELECT @@SPID AS TestSession;
WAITFOR DELAY '00:00:30';Read Attention Events From the Event File
sys.fn_xe_file_target_read_file reads the captured event files through a server-visible path. Convert event_data to XML and extract the timestamp and actions. The wildcard includes the target's rollover files. Keep the file location consistent with the capture definition.
The result describes cancellations captured during the session's lifetime. Files can be rolled over, and SQL text availability depends on the request context. A missing text value needs investigation, not a guessed statement. Retain the session identifier and application alongside it.
Check timestamp interpretation before comparing it with application logs. Extended Events timestamps use UTC semantics in the event payload. A local display or exported datetime without its original offset can make two related events appear unrelated. Preserve the source timestamp representation when precise correlation matters, and translate it through a documented reporting rule.
WITH Events AS
(
SELECT TRY_CONVERT(xml,event_data) AS EventXML
FROM sys.fn_xe_file_target_read_file(N'C:\SqlEvents\CancelCapture*.xel',NULL,NULL,NULL)
)
SELECT EventXML.value('(event/@timestamp)[1]','datetime2') AS EventTimeUTC,
EventXML.value('(event/action[@name="session_id"]/value)[1]','int') AS SessionID,
EventXML.value('(event/action[@name="client_app_name"]/value)[1]','nvarchar(256)') AS ApplicationName,
EventXML.value('(event/action[@name="sql_text"]/value)[1]','nvarchar(max)') AS StatementText
FROM Events ORDER BY EventTimeUTC;Check Attention Events Against Query Store and Transactions
Query Store runtime statistics can record execution_type_desc equal to Aborted for captured executions. That supplies a durable aggregate perspective when Query Store captured the relevant work. It is not a one-event-per-row cancellation log and does not explain the client's reason.
The next query lists captured aborted runtime rows with their query text and intervals. Correlate them with the event and workload window. New or uncaptured requests can be absent, so an empty result is not proof that the attention capture was wrong.
A canceled statement can leave an open transaction depending on the batch and error-handling design. Review the owning session and open_transaction_count after cancellation. SET XACT_ABORT ON is an important part of reliable modification handling, but the application must still handle cancellation and connection cleanup correctly. Do not assume a timeout automatically committed or rolled back every surrounding operation.
SELECT q.query_id,p.plan_id,i.start_time,i.end_time,r.count_executions,qt.query_sql_text
FROM sys.query_store_runtime_stats AS r
JOIN sys.query_store_plan AS p ON p.plan_id=r.plan_id
JOIN sys.query_store_query AS q ON q.query_id=p.query_id
JOIN sys.query_store_query_text AS qt ON qt.query_text_id=q.query_text_id
JOIN sys.query_store_runtime_stats_interval AS i ON i.runtime_stats_interval_id=r.runtime_stats_interval_id
WHERE r.execution_type_desc='Aborted'
ORDER BY i.start_time DESC;End the Capture and Investigate the Delay
Stop and drop the temporary session after saving the relevant evidence. Keep the event files only under the approved diagnostic retention policy. The cleanup below removes the session definition, not the saved files. Confirm the target name before executing it.
Investigate the canceled request's plan, waits, blocking, and client timeout policy through focused follow-up. Increasing a timeout can hide a delay without fixing its cause. Equally, a deliberate cancellation of an unnecessary report is not proof of a server performance failure. Correlate each captured event with the exact test action before attributing it to a client timeout.
Attention events make otherwise quiet cancellations visible. Pair them with application context, Query Store evidence where available, and a transaction-state check. The complete diagnosis explains both why the work was interrupted and what happened to the connection afterward.
ALTER EVENT SESSION CancelCapture ON SERVER STATE=STOP;
DROP EVENT SESSION CancelCapture ON SERVER;Related reading on this blog: Capturing Execution Plan for Canceled Query and SQL Server: Understanding Connection Timeouts and Query Timeouts.
A cancellation is not a root cause, it is an interrupted request that needs context.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
