Observed complexity budget exhausted for board graphQL api with latest version

We are observing complexity issue with board graphQL api with minimal response properties and a limit of 10 records only.
Is this an expected behavior?

items_count carries a very high complexity compared to any other property. It is 5000 per board returned.

10 for board root = 10
10 boards X 5000 = 50000
10 boards X 5 properties (beside items_count) = 50

50000+50+10 = 50060.

Do we have any documentation on which properties are high in complexity?

monday has never published a list, nor details on how its calculated specifically.

Use this rule of thumb:
Queries like items_page and items_page_by_column_value are going to be expensive to start with. 3000 for items_page, each board its called on, if you query multiple boards at once, 3000* number of boards.

Root query objects like boards, items, workspaces, etc. are 10, updates i believe is 25 due to the large size.

Most properties are 1, but a few are large, the only one that jumps at me is items_count on boards or groups.

Nesting subitems in items is expensive - 1000 * the number of properties requested for the subitem, even if none are returned.

Best way to figure it out, is to experiment in the playground, and return complexity. Once you get a feel for it, you can start to learn when and how to split queries up (maybe get items and the subitems column value, then parse the value for a list of subitems to query directly using an items query.) To what extent you take it is up to the needs of your application.

I am not an employee of monday.com

Hello there @csprod2box,

You can also calculate the complexity usage for your calls by adding something like this:

mutation {
  complexity {
  create_item(board_id:1234567890, item_name:"test item") {

I hope that helps!


1 Like