Power BI refresh failing with SQL error 596 – “session is in the kill state”

SQL error 596 (“session is in the kill state”) is fundamentally SQL Server side: it means the SQL session executing your refresh query was killed (explicitly via KILL, by a DBA/job, by failover, resource governor, timeouts/cancellation, or an underlying severe error that forces the session to die). Power BI / the gateway is just the client that happened to be using that session.

1) Make sure incremental refresh is truly folding

If your RangeStart/RangeEnd filter isn’t folding all the way into SQL, Power BI may pull far more data than expected, making queries slow/heavy and more likely to be killed. In Power Query, verify folding on the step that applies RangeStart/RangeEnd (View Native Query should be enabled).

2) Reduce refresh query cost (biggest “Power BI-side” win)

• Avoid complex M transformations before the foldable filter.

• Push heavy joins/aggregations into:

  • a SQL view

  • or (better) a stored procedure / prepared table

• Keep the Power BI query as close to SELECT ... FROM <prepared object> WHERE Date between RangeStart/RangeEnd as possible.

Hi manoj_0911 

SQL error 596 is fundamentally a SQL Server–side termination, not a Power BI bug, but Power BI refresh patterns can definitely make it more likely to happen. This error means the SQL session used by the gateway was forcefully killed while a command was executing, which commonly happens due to resource pressure (memory, tempdb, CPU), query timeouts, blocking, or an automated kill from SQL Server (for example via resource governor, maintenance jobs, failover, or monitoring tools). The reason you only see it intermittently during incremental refresh is that incremental refresh still runs heavy range-based queries and aggregations, and when these overlap with peak load, index maintenance, backups, or long-running blocking sessions, SQL may terminate the connection and Power BI surfaces it as error 596. From a Power BI side, the best mitigations are to ensure incremental refresh is truly folding to SQL (verify query folding), reduce transformations in Power Query, avoid unnecessary joins or calculated columns during refresh, and keep partition ranges small enough to limit each refresh window’s workload. On the SQL side, make sure the filtered date columns used for incremental refresh are indexed, check for blocking and deadlocks during the refresh window, review Resource Governor or any automated kill scripts, and confirm tempdb is not under pressure. In real-world setups, this issue almost always disappears once the SQL workload is stabilized and the refresh window is aligned away from heavy database activity, rather than by changing Power BI alone.