Azure SQL and Logic Apps: Are We Paying for a Managed Service or Managing Azure’s Shortcomings?

Details:

I’m Sasha Froyland, founder of Help4Access, and I’m reaching out to the Azure community because my team and I have spent the past six months troubleshooting what should be a "managed" service—Azure SQL Database—and Logic Apps. Instead, we’ve encountered inconsistencies, misleading error messages, and a scaling mechanism that seems more like a gamble than a predictable process.

Let me provide a summary of the issues we’ve faced:

Azure SQL Database

Misleading Error Messages:

• Errors like “Stored procedure not found” or “Not Found” appeared when the actual issue was resource starvation at lower tiers. Why does the error handling system blame application logic instead of resource constraints? This misdirection has cost us countless hours.

Scaling Inconsistencies:

  - Despite running scaling commands (e.g., `ALTER DATABASE MODIFY`), querying the `sys.database_service_objectives` view often returned stale values. We’d wait the prescribed time, only to find the scale-up hadn’t taken effect.
  
     - Lower service tiers (S1-S3) routinely led to random, intermittent errors. The result? A constant juggling act of resource tiers without consistent feedback from the platform.
     
     **Resource Starvation**:
     
        - At service levels below S4, jobs that rely on moderate CPU and I/O fail unpredictably, even with no competing workloads. Is this an issue with Azure's throttling or just an under-documented limitation?
        
        **“Managed” Service in Name Only**:
        
           - Why are we refreshing metadata, updating stats, and babysitting Azure SQL to prevent it from choking on operations? Isn’t the whole point of a managed service to avoid this?
           

Logic Apps

Error Propagation:

• Logic Apps consistently passed vague or outright misleading errors to our monitoring systems. “Not Found” doesn’t mean what it says, and pinpointing the issue required more digging than necessary.

Scaling and Concurrency Conflicts:

  - Logic Apps performed unpredictably during scale-up and scale-down operations. High-resource workflows frequently failed when scaling coincided with job execution.
  
  **Poor Debugging Experience**:
  
     - Debugging failures in Logic Apps often feels like spelunking without a flashlight. Why is there no better visibility into what’s happening at runtime?
     
     **Random Failures**:
     
        - Workflows that run clean for months suddenly start failing for no discernible reason. Logic Apps often leave us questioning what changed when nothing in our configurations did.
        

Bigger Picture

We’ve spent over 200 hours chasing our tails—rewriting code, splitting workflows, revalidating logic—all to discover the root causes weren’t in our hands. The promise of Azure as a "managed service" is increasingly hard to believe when we’re acting as its de facto babysitters.

I get it—no system is perfect. But when these issues directly impact business operations, leading to wasted resources and frustration, it’s a problem worth highlighting.

Questions for the Community

• Has anyone else encountered these issues, particularly with scaling and misleading error messages? If so, how have you addressed them?
• Are there any tools or processes to reliably manage Azure SQL scaling operations and improve transparency during Logic App execution?
• Is Microsoft aware of how much these inconsistencies cost businesses, and are they actively addressing them?

I’d love to hear feedback from other professionals on how to navigate these challenges—or if this is just the cost of doing business with Azure. Right now, it feels like Azure SQL and Logic Apps are only as good as our ability to manage their flaws.Details:

I’m Sasha Froyland, founder of Help4Access, and I’m reaching out to the Azure community because my team and I have spent the past six months troubleshooting what should be a "managed" service—Azure SQL Database—and Logic Apps. Instead, we’ve encountered inconsistencies, misleading error messages, and a scaling mechanism that seems more like a gamble than a predictable process.

Let me provide a summary of the issues we’ve faced:

Azure SQL Database

Misleading Error Messages:

• Errors like “Stored procedure not found” or “Not Found” appeared when the actual issue was resource starvation at lower tiers. Why does the error handling system blame application logic instead of resource constraints? This misdirection has cost us countless hours.

Scaling Inconsistencies:

  - Despite running scaling commands (e.g., `ALTER DATABASE MODIFY`), querying the `sys.database_service_objectives` view often returned stale values. We’d wait the prescribed time, only to find the scale-up hadn’t taken effect.
  
     - Lower service tiers (S1-S3) routinely led to random, intermittent errors. The result? A constant juggling act of resource tiers without consistent feedback from the platform.
     
     **Resource Starvation**:
     
        - At service levels below S4, jobs that rely on moderate CPU and I/O fail unpredictably, even with no competing workloads. Is this an issue with Azure's throttling or just an under-documented limitation?
        
        **“Managed” Service in Name Only**:
        
           - Why are we refreshing metadata, updating stats, and babysitting Azure SQL to prevent it from choking on operations? Isn’t the whole point of a managed service to avoid this?
           

Logic Apps

Error Propagation:

• Logic Apps consistently passed vague or outright misleading errors to our monitoring systems. “Not Found” doesn’t mean what it says, and pinpointing the issue required more digging than necessary.

Scaling and Concurrency Conflicts:

  - Logic Apps performed unpredictably during scale-up and scale-down operations. High-resource workflows frequently failed when scaling coincided with job execution.
  
  **Poor Debugging Experience**:
  
     - Debugging failures in Logic Apps often feels like spelunking without a flashlight. Why is there no better visibility into what’s happening at runtime?
     
     **Random Failures**:
     
        - Workflows that run clean for months suddenly start failing for no discernible reason. Logic Apps often leave us questioning what changed when nothing in our configurations did.
        

Bigger Picture

We’ve spent over 200 hours chasing our tails—rewriting code, splitting workflows, revalidating logic—all to discover the root causes weren’t in our hands. The promise of Azure as a "managed service" is increasingly hard to believe when we’re acting as its de facto babysitters.

I get it—no system is perfect. But when these issues directly impact business operations, leading to wasted resources and frustration, it’s a problem worth highlighting.

Questions for the Community

• Has anyone else encountered these issues, particularly with scaling and misleading error messages? If so, how have you addressed them?
• Are there any tools or processes to reliably manage Azure SQL scaling operations and improve transparency during Logic App execution?
• Is Microsoft aware of how much these inconsistencies cost businesses, and are they actively addressing them?

I’d love to hear feedback from other professionals on how to navigate these challenges—or if this is just the cost of doing business with Azure. Right now, it feels like Azure SQL and Logic Apps are only as good as our ability to manage their flaws.