Azure SQL MANAGED INSTANCE error 80071bc9. [CFabricCommonUtils::GetFabricPropertyInternalWithRef] EndGetProperty call failed for property: SpaceToReserveInMB with result: 80071bc9

Jorge 0 Reputation points
2026-10-01T06:33:54.62+00:00

We are running a Failover group between two instances in Azure SQL Managed instance and we noticed that we faced the same total disconnection issue of SQL clientes, when both instances reach between the 84% to 90% of storage limit.

We found that by the time the primary instance disconnects all SQL clients, the following server log error occurred:

30/09/2026 23:32:25 spid30s [DISK_SPACE_TO_RESERVE_PROPERTY]: Property not found or failed to get the property with [80071bc9].
30/09/2026 23:32:25 spid30s [CFabricCommonUtils::GetFabricPropertyInternalWithRef] EndGetProperty call failed for property: SpaceToReserveInMB with result: 80071bc9

in both cases the databases primary instance was unable to accept incoming connections and we don't know why and what kind of event triggered that behaviour.

We did not find any documentation related to the required free storage space to let the primary and secondary instances to work properly within the backup configuration we have: PITR 7 days LTR 4 weeks.

Is there any official documentation which states the free available storage we need to keep for the instances to work and run backup + failover operations without any service interruption?

Azure SQL Database
0 comments No comments

3 answers

Sort by: Most helpful
  1. Rukshan edirisinghe 910 Reputation points
    2026-10-02T05:21:09.59+00:00

    Hi @Jorge

    Sorry about the partner runaround. On the documentation point, there isn't an official "keep X% free" number for Managed Instance, and I'd rather be straight about that than invent one. What the docs do define is the mechanism that bites you, and it explains the 84 to 90% pattern.

    On Managed Instance, storage usage is counted as allocated file sizes, including tempdb and every log file. The limits docs say tempdb can grow up to 24 GB per vCore, but only within the currently available instance storage, which is defined as reserved size minus used space. The same applies to log file growth. So once allocated space gets close to the limit, a tempdb or log autogrow fails, and that's when connections start failing instance-wide even though your data files look fine. Backups don't take instance storage at all, PITR and LTR go to separate backup storage, so your retention settings aren't the trigger.

    The one change that addresses it:

    1. Give the instance real headroom by increasing reserved storage from Compute + storage. Storage-only changes are online with no failover. Aim to keep allocated space comfortably below the limit, with room for tempdb at its 24 GB per vCore maximum plus your largest log file's normal growth.
    2. Watch it with this on each instance, and alert at around 75%:
       SELECT TOP 1 reserved_storage_mb, storage_space_used_mb,
              CAST(storage_space_used_mb*100.0/reserved_storage_mb AS decimal(5,1)) AS pct_used
       FROM master.sys.server_resource_stats ORDER BY end_time DESC;
    

    The Fabric property error you quoted is an internal platform lookup, so only Microsoft can read what happened behind it. If you want that investigated, a CSP partner is required to provide support for subscriptions they sell and can escalate to Microsoft through Partner Center, so it's fair to push back on Crayon. Moderators here can also pass your instance details to the product team by private message.

    Could you check the error log around 23:32 for errors 1105 or 9002, and let me know whether these are General Purpose or Business Critical instances? That confirms which file hit the wall.

    If this helped, please click Accept Answer so others hitting this at high storage usage can find it.

    Reference: https://learn.microsoft.com/en-us/azure/azure-sql/managed-instance/resource-limits

    Was this answer helpful?

    0 comments No comments

  2. Jorge 0 Reputation points
    2026-10-02T03:52:53.8166667+00:00

    Thanks Erland for your response.We tried to locate more errors or logs related to the Fabric link but no clue at all. We tried to get the Microsoft support via our partner: Crayon (now SoftwareOne) but they refused to provide due to they consider is a Microsoft vendor issue.... what to say!
    Thanks

    Was this answer helpful?

    0 comments No comments

  3. Erland Sommarskog 137.5K Reputation points MVP Volunteer Moderator
    2026-10-01T20:24:17.9833333+00:00

    Do you use Fabric Link or any other Fabric-related feature? (I mean the error message points to so something Fabric-related.)

    To me this does not sound right, but something Microsoft should investigate. I would advice you to open a support case through the portal. Depending on your support policy, you may still end up here in Microsoft Q&A, but Microsoft support staff will have to pick it up, and possibly escalate it to the product group after investigations.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.