Use ABORT_QUERY_EXECUTION to block query execution in SQL Server 2025

ABORT_QUERY_EXECUTION is a new query hint (SQL Server 2025 / 17.x) designed as an emergency brake: it blocks future executions of a query you have identified as a problem — excessive CPU or I/O consumption, a runaway query, non-essential reporting that endangers a critical workload, and so on.

Added as a query hint, it makes the query fail immediately.

Its real value in production comes from combining it with a Query Store Hint: you can block one specific query, identified by its query_id in the Query Store, without touching the application code.

What it actually does

• The query fails immediately with error 8778 (severity 16): “Query execution has been aborted because the ABORT_QUERY_EXECUTION hint was specified.”
• The intended use is administrative, through the Query Store, so that no application code has to change.
• It does not stop a query that is already running: it only applies to future executions. To stop a running execution, use KILL.
• You cannot block an “unknown” query: at least one execution must have been recorded in the Query Store, even one that failed, timed out or was cancelled.
• ABORT_QUERY_EXECUTION is available on Azure SQL Database, Azure SQL Managed Instance, and SQL Server 2025 (17.x).

This is not a configurable timeout. It is a ban on executing a query identified through the Query Store — a governance mechanism, not a tuning knob.

Enabling the hint in the Query Store

The Query Store must be enabled.

You need to identify the query_id of the query to block, then apply the ABORT_QUERY_EXECUTION hint with the sys.sp_query_store_set_hints stored procedure.

Identify the query_id to block

You can either:

• use the Query Store reports in SSMS, or
• query the catalog views.

Hints are managed with:

• sys.sp_query_store_set_hints to create or update them;
• sys.sp_query_store_clear_hints to remove them;
• the sys.query_store_query_hints catalog view for visibility and diagnosis.

Setting or removing these hints requires ALTER permission on the database.

Apply the query hint

EXEC sys.sp_query_store_set_hints
     @query_id    = 39,
     @query_hints = N'OPTION (USE HINT (''ABORT_QUERY_EXECUTION''))';

Every future execution of the query attached to query_id = 39 fails with error 8778.

Check that the query is really blocked

The sys.query_store_query_hints view exposes the hint text, its state, and the reasons for failure if a hint could not be applied.

SELECT query_hint_id,
       query_id,
       replica_group_id,
       query_hint_text,
       last_query_hint_failure_reason,
       last_query_hint_failure_reason_desc,
       query_hint_failure_count,
       source,
       source_desc
FROM sys.query_store_query_hints
WHERE query_id = 39;

Unblock the query

You can remove every hint for the query_id:

EXEC sys.sp_query_store_clear_hints @query_id = 39;

If you had several hints and want to keep the others, run sp_query_store_set_hints again with only ABORT_QUERY_EXECUTION removed.

Inventory every blocked query

To list all the queries blocked through ABORT_QUERY_EXECUTION:

SELECT qh.query_id,
       qh.query_hint_text,
       qh.query_hint_failure_count,
       qh.last_query_hint_failure_reason_desc,
       qt.query_sql_text
FROM sys.query_store_query_hints AS qh
JOIN sys.query_store_query AS q
  ON q.query_id = qh.query_id
JOIN sys.query_store_query_text AS qt
  ON qt.query_text_id = q.query_text_id
WHERE qh.query_hint_text LIKE N'%ABORT_QUERY_EXECUTION%'
ORDER BY qh.query_id DESC;

When the hint is present but does not apply

Look at sys.query_store_query_hints, and specifically at:

• last_query_hint_failure_reason_desc
• query_hint_failure_count

Readable secondaries

SQL Server 2025 strengthens Query Store support on readable secondary replicas, in availability group scenarios, and sys.sp_query_store_set_hints exposes a @replica_group_id parameter to control the scope of the hint per replica group.

• You may want to block a query only on a readable secondary used for reporting, without affecting the primary — or the other way round, depending on your architecture.
• This becomes a finer governance lever once the workloads are separated, with reads and reporting on one side and OLTP on the other.

References

• Query Store hints best practices