Something is funky with the complexity calculations. Same query - within 12 hour timespan - is 25 times smaller.

PLEASE FIX!

Hey @bmack

I think the issue could be related to the recent change in API complexity:

https://api.developer.monday.com/changelog/increased-complexity-for-the-users-query

I’d love it if it was only a 10x increase. But what I’m seeing on my account is much, much higher.

Additionally, the above query in the screenshot is for subitems - and doesn’t explain the complexity change.

I also can’t explain why its happening every 5 mins. There’s no way to see what user, integration, automation may be responsible. I have over 400 users - I’d have to disable their accounts to block this - but doing so removes them from board ownership, automation owners, etc. - and does not reapply if enabled.

This is problematic that we cannot see what API keys, users - are using our account.

Hi @bmack,

Your issue is to do with the limit you have provided in the items query.

Last night, you were retrieving 25 items per board, tonight you are retrieving 1 item per board.

This is the 25x difference in your complexity.

@bmack

In terms of your initial post, it might be worth reaching out to appsupport@monday.com as they should be able to look further into some of the requests being made on your account.

One note, the complexity limit is account wide. This applies to all apps that are installed on your account so it may be an integration/board view that is using up the complexity.

I definitely missed that, apologies.

hi @mitchell.hudson

I don’t know if there has been a very recent change but complexity counters used to be per app / per account. Each app receives 5M read + 5M write per minute.

We are resetting API keys and starting to disable users but this problem persists. It is occuring every five minutes. There is no way to figure what is causing this issue.

WARNING: 05/02/2022 22:04:34 | Reset: 51 secs. | Avail: 100.00% | Remaining: 10000000 | Used: 0

WARNING: 05/02/2022 22:04:36 | Reset: 49 secs. | Avail: 100.00% | Remaining: 10000000 | Used: 0

WARNING: 05/02/2022 22:04:38 | Reset: 47 secs. | Avail: 100.00% | Remaining: 10000000 | Used: 0

WARNING: 05/02/2022 22:04:40 | Reset: 45 secs. | Avail: 100.00% | Remaining: 10000000 | Used: 0

WARNING: 05/02/2022 22:04:42 | Reset: 43 secs. | Avail: 100.00% | Remaining: 10000000 | Used: 0

WARNING: 05/02/2022 22:04:45 | Reset: 40 secs. | Avail: 100.00% | Remaining: 10000000 | Used: 0

WARNING: 05/02/2022 22:04:47 | Reset: 38 secs. | Avail: 100.00% | Remaining: 10000000 | Used: 0

WARNING: 05/02/2022 22:04:49 | Reset: 36 secs. | Avail: 100.00% | Remaining: 10000000 | Used: 0

WARNING: 05/02/2022 22:04:51 | Reset: 34 secs. | Avail: 100.00% | Remaining: 10000000 | Used: 0

WARNING: 05/02/2022 22:04:53 | Reset: 32 secs. | Avail: 100.00% | Remaining: 10000000 | Used: 0

WARNING: 05/02/2022 22:04:55 | Reset: 30 secs. | Avail: 100.00% | Remaining: 10000000 | Used: 0

WARNING: 05/02/2022 22:04:57 | Reset: 27 secs. | Avail: 100.00% | Remaining: 10000000 | Used: 0

WARNING: 05/02/2022 22:05:00 | Reset: 25 secs. | Avail: 100.00% | Remaining: 10000000 | Used: 0

WARNING: 05/02/2022 22:05:02 | Reset: 23 secs. | Avail: 71.99% | Remaining: 7199476 | Used: 2800524

WARNING: 05/02/2022 22:05:04 | Reset: 21 secs. | Avail: 43.99% | Remaining: 4398952 | Used: 5601048

WARNING: 05/02/2022 22:05:06 | Reset: 19 secs. | Avail: 15.98% | Remaining: 1598428 | Used: 8401572

WARNING: 05/02/2022 22:05:08 | Reset: 16 secs. | Avail: 1.98% | Remaining: 198166 | Used: 9801834

WARNING: 05/02/2022 22:05:11 | Reset: 14 secs. | Avail: 1.98% | Remaining: 198166 | Used: 9801834

WARNING: 05/02/2022 22:05:13 | Reset: 12 secs. | Avail: 1.98% | Remaining: 198166 | Used: 9801834

WARNING: 05/02/2022 22:05:15 | Reset: 10 secs. | Avail: 1.98% | Remaining: 198166 | Used: 9801834

WARNING: 05/02/2022 22:05:17 | Reset: 8 secs. | Avail: 1.98% | Remaining: 198166 | Used: 9801834

WARNING: 05/02/2022 22:05:19 | Reset: 6 secs. | Avail: 1.98% | Remaining: 198166 | Used: 9801834

WARNING: 05/02/2022 22:05:21 | Reset: 4 secs. | Avail: 1.98% | Remaining: 198166 | Used: 9801834

WARNING: 05/02/2022 22:05:24 | Reset: 1 secs. | Avail: 1.98% | Remaining: 198166 | Used: 9801834

WARNING: 05/02/2022 22:05:26 | Reset: 60 secs. | Avail: 100.00% | Remaining: 10000000 | Used: 0

WARNING: 05/02/2022 22:05:28 | Reset: 58 secs. | Avail: 100.00% | Remaining: 10000000 | Used: 0

WARNING: 05/02/2022 22:05:30 | Reset: 56 secs. | Avail: 100.00% | Remaining: 10000000 | Used: 0

Hi Guys,

I am having a similar issue. I have been running calls via integromat for many months and all the sudden they all error out hitting the limit. A simple GET /itemid is costing 480,129 complexity points. What is going on???

Bump this thread - also have the same issue where scripts that use to run without any issue with complexity now routinely hit the global 10MM limit…

Do you need the subitems? That seems to be the common thread I see in these complaints about query costs. Esp true if column values of subitems are being returned. Integromat definitely does that. You can uncheck the Show Subitems (and Show Parent Item if its not a subitem board) to reduce complexity.

In many cases you can use an alternative for queuering subitem column values. If you query the parent board and retrieve the boardId where the subitems live you can query the subitems as normal items (preventing the nesting). This is definitely cheaper (but not always possible).

Esp since Integromat/Make will get all column values of the subitems, when you may only need one.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.