AnyKanban

Docs › Work with others

When Azure DevOps rate-limits you

Azure DevOps meters each user against a consumption budget over a rolling five-minute window, and a busy morning can push you over it: a large cross-project board open in several tabs, an export you are running, or a script or pipeline that runs with your own access token. When that happens the board says so, pauses, and comes back on its own instead of going blank and looking broken.

Steps

  1. Look at the top of the board for the warning card: "Updates are paused because Azure DevOps is temporarily limiting requests. Wait until … for refreshing to resume.".
  2. Note the time it names. That is when the board expects the service to accept traffic again; the message removes itself within a second of the pause lapsing.
  3. Carry on moving cards. A drag made during the pause is not thrown away. The write waits out the window and goes through when it reopens. One kind of reorder is the exception: when the cards around the drop have no room left between their ranks, the board has to read that stretch first, and it cannot while the pause lasts. The card keeps its order, the message says to try the move again, and once the pause is over the same move works (see Put a column in priority order).
  4. Avoid pressing Refresh while the warning is showing. Refresh reloads the whole board, so the cards and columns are replaced by a loading indicator until the pause ends, and it does not shorten the pause. The reload waits and tries again a few times; if the service is still refusing by then, the board keeps retrying on its own and appears when requests are accepted again.
  5. If the board was still opening when the limit hit, read the error instead: "Azure DevOps is limiting requests from this account. AnyKanban will keep retrying, and the board will load when requests are accepted again." There is nothing to press: the board re-attempts the load on its own and appears when the window reopens.
  6. If the warning keeps returning, reduce what is open. Every tab showing a board re-runs its query on its own timer: every 20 seconds while the tab is in front, and every two minutes while it sits in the background. Each tab also loads the whole board when it opens, and checks again as soon as you switch back to it. Boards showing side by side in separate windows cost the most, because each one refreshes every 20 seconds.

What you should see

One discreet warning card at the top of the board, not a message per refused call. Unless you press Refresh, nothing disappears while it is showing: the cards, the columns and the counts stay exactly as they were, they simply stop updating. Background refreshes are skipped rather than queued, so when the window reopens the board takes one ordinary refresh instead of firing every cycle it missed.

Your own work still lands. A card you drag during the pause moves on screen at once, its write waits, and the revision check still protects it when it resumes, so a resumed write cannot overwrite a change someone else made in the meantime.

Notes

While the pause is on, columns your process rules would reject may stop dimming as you drag: that dimming comes from a check that is itself a read, and reads are skipped. The drop is still attempted and the server still refuses it, with its own message. You lose the warning, not the protection.

How long the pause lasts is the service's decision, taken from the Retry-After value it sends. That header is frequently not visible to code running inside an extension frame, in which case the board waits five seconds and doubles that for each further pause it has to guess at. A single pause never exceeds five minutes.