Forum Discussion
OData 503 Error in Power BI When Using Custom Parameter from Azure DevOps
- 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
- Ensuring that the custom parameter is correctly configured in Azure DevOps.
- Checking for any issues with service availability on Azure DevOps (none found).
- Querying the data without the custom parameter, which works without issues.
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.
9 Replies
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. ✅
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.
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!
Add pagination (most common fix):
&$top=500
Simplify query (remove unnecessary expansions):
/_odata/v3.0/WorkItems?$select=WorkItemId,CustomDateField&$filter=AssignedTo/UserName eq 'Bob'&$top=500
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.
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`?
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.
