Hi @priyagautam12 ,
Thanks for raising this — what you described is definitely frustrating, and you're right to expect more control as a developer.
Currently, in Microsoft Fabric, developers don’t have direct access to cancel long-running or stuck SQL queries once they’ve been submitted to the capacity. If the query consumes all available compute (like in your F16 case), it can block other operations, and unfortunately, pausing the capacity is often the only way to forcefully release it via admin tools.
Here are a few things you might consider:
Use Query Timeout Settings (if available)
While not exposed in all interfaces yet, some environments allow setting a timeout at the query or session level. If you're using notebooks or pipelines, you might be able to wrap the query in a timeout logic.
Break Down Complex Joins
Joining 10–12 large tables in one go can be risky, especially if the lakehouse tables are not optimized (e.g., no distribution or indexing). Try breaking the logic into intermediate views or temp tables to reduce compute pressure.
Monitor with Capacity Metrics App
If you haven’t already, install the Fabric Capacity Metrics App — it helps track which queries are consuming resources and might help you catch runaway queries earlier.
Submit Feedback to Microsoft
This is a known limitation and has been raised by others too. I’d recommend submitting this via the Fabric feedback portal — more voices help prioritize this kind of developer control.
Let me know if you want help optimizing the query or breaking it into smaller parts — happy to take a look.
If my response resolved your query, kindly mark it as the Accepted Solution to assist others. Additionally, I would be grateful for a 'Kudos' if you found my response helpful.
Translation and text formatting supported by AI assistance
