OData 503 Error in Power BI When Using Custom Parameter from Azure DevOps

[GuilhermeMorett]

Hello, Power BI Community,

I’m encountering an issue when trying to query Azure DevOps using the OData feed in Power BI. When I attempt to include a custom parameter from a User Story (US), I receive the following error:

DataSource.Error: DataSource.Error: OData: Request failed: The remote server returned an error: (503) Server Unavailable. (Service Unavailable). Microsoft.Data.Mashup.ErrorCode = 10122. DataSourceKind = OData.

Interestingly, when I remove the custom parameter from the User Story and run the query again, it works fine. However, including this custom parameter seems to trigger the 503 error.

Here are the details of my setup:

• Data Source: Azure DevOps OData Feed 
• Error Message: 503 (Service Unavailable) 
• Custom Parameter: This parameter is a Custom Date 
• Environment: Power BI Desktop, Azure DevOps Services 

I’ve already tried:

1. Ensuring that the custom parameter is correctly configured in Azure DevOps.
2. Checking for any issues with service availability on Azure DevOps (none found).
3. Querying the data without the custom parameter, which works without issues.

Has anyone encountered a similar problem or has insights into why this might be happening? Any suggestions or solutions would be greatly appreciated!

Plus: This is happening locale and when I publish and use refresh data source.

[v-pagayam-msft]

Hi @GuilhermeMorett ,
I wanted to follow up on the previous suggestions regarding the issue. We would like to hear back from you to ensure we can assist you further.
If our response has addressed your query, please accept it as a solution and give a ‘Kudos’ so other members can easily find it. Please let us know if there’s anything else we can do to help.
Thank you.

Regards,
Pallavi.

[GuilhermeMorett]

Hello again, @anilelmastasi  🙂

I’ve optimized my OData query by reducing the number of selected fields and limiting the request to only what’s necessary — specifically WorkItemId and a crucial custom date field.

Here’s the current query:

_odata/v3.0/WorkItems?$select=WorkItemId&$expand=Parent($select=WorkItemId,Custom_a081288e__00jdas35__00sdfghj44d__002D99b7__002D9e80aee11c31),AssignedTo($select=UserName),Area($select=AreaPath)&$filter=AssignedTo/UserName eq 'Bob'

Despite the optimization, I’m still receiving a 503 Service Unavailable error.

The custom date field (Custom_a081288e__00jdas35__00sdfghj44d__002D99b7__002D9e80aee11c31) is essential to my analysis.
Is there anything else I can do to resolve this issue? Could this be related to system limits or performance throttling?

Any guidance would be greatly appreciated. Thank you in advance!

[Naila-Rais]

1. Add pagination (most common fix):

   &$top=500

2. Simplify query (remove unnecessary expansions):

   /_odata/v3.0/WorkItems?$select=WorkItemId,CustomDateField&$filter=AssignedTo/UserName eq 'Bob'&$top=500

3. If still failing, try:

   /_odata/v3.0/WorkItems?$select=WorkItemId&$filter=AssignedTo/UserName eq 'Bob'&$top=100

   Then get details in separate calls per WorkItemId.

Note: 503 usually means server overload - smaller requests work best.

[GuilhermeMorett]

Hello Naila,

Thank you for your suggestion. Unfortunately, it did not work for me. I need to retrieve the Custom Date field from the parent record, and if I remove the `$expand` clause, the query fails.

Could you please advise how I can obtain the Custom Date from the parent without removing `$expand`?

[v-pagayam-msft · Accepted solution]

Hi @GuilhermeMorett  ,
Thank you Naila-Rais  and anilelmastasi   for the insightful responses! 

• When using $expand, ensure you're selecting only the necessary fields to reduce the complexity of the query. This can help mitigate performance issues and potential 503 errors.
• Instead of expanding the parent work item within your main query, consider executing a separate query to fetch the parent work item's custom date field. You can then merge this data with your child work items in Power BI.
• Be aware of Azure DevOps service might  limits and throttling policies. Exceeding these limits might result in 503 errors.  It's advisable to pause operations and retry after some time.
  

  Hope this resolve your query.If so,give us kudos and consider accepting it as solution.
  
  Regards,
  Pallavi G.

[v-pagayam-msft]

Hi @GuilhermeMorett ,
Just checking in — did the solution provided help resolve your issue? If yes, please consider marking it as the accepted answer so it can help others facing a similar challenge.If still needed further assistance, feel free to reachout!

Thank you.

[v-pagayam-msft]

Hi @GuilhermeMorett ,
I hope the suggested solution worked for you. If your issue is resolved, kindly accept the post as a solution — it helps the community identify helpful answers more easily. If still having any issues, feel free to reachout!

Thank you.

[anilelmastasi]

Hello @GuilhermeMorett ,

Thank you for detailed description of your issue. Custom fields on Azure DevOps OData are often slower or less stable because they are pulled from an extended schema. Not all custom fields are fully exposed or optimized in the OData layer. OData feed performance degrades with wide and complex queries, especially when many fields are included, and especially across large datasets. 503 error usually means the backend service is overwhelmed or unable to process your request. When you include the custom parameter (especially if it’s a custom Date field), the OData query becomes more complex, and the API may hit resource limits, take too long to respond (timeout) or hit throttling thresholds.

To fix this you may reduce the scope of the query

Try pulling only the ID and the custom field (Custom Date) — no other columns — and test if that works.

This helps isolate if the problem is the field itself or the combination of fields.

If this solved your issue, please mark it as the accepted solution. ✅

[GuilhermeMorett]

Hi @anilelmastasi !
The suggestion given helped solve the problem.
I added WorkItemType and Status in my case to reduce the amount of returns and jobs.
I was using one query with all the parameters I needed (including the custom parameter), but now I split one query for the custom parameter and another query for the other parameters.

Fun fact: 
I had been using the full query for a few months without any problems, but overnight this error appeared.