Get help on Discord

Max listener limit exceeded at 1004 error in Sanity Studio

7 replies
Last updated: Jun 23, 2021
Hi Sanity fam, I've been working on a project for a client and just started receiving some Javascript errors stating: 
Error: Max listener limit exceeded at 1004
. This started intermittently yesterday and said 
at 1001
. It has since stopped being intermittent and is now permanently stating 
Error: Max listener limit exceeded at 1004
. I previously figured it was due to some complex deskStructure stuff going on but have now completely removed all the complexities and am attempting to load an 
S.editor()
for a specific ID and it's not loading a thing. Restarted the local instance of Studio, cleared by cookies and cache.
Thoughts?
AI Update

Hey there! This is a tricky one, but the "Max listener limit exceeded at 1004" error you're seeing is actually hitting a platform-level limit on concurrent listeners to Sanity's real-time APIs.

Based on the technical limits documentation, Sanity enforces maximum concurrent listener limits per project plan:

  • Free plan: 1,000 listeners
  • Growth plan: 5,000 listeners
  • Enterprise plan: 10,000 listeners

You're hitting the 1,004 listener mark, which suggests you're on a Free plan and have exceeded the 1,000 concurrent listener threshold.

What's causing this?

Each time Studio opens a document or subscribes to real-time updates, it creates listener connections. These can accumulate from:

  1. Multiple Studio instances - Every browser tab/window with Studio open creates listeners
  2. Document subscriptions - Each open document view subscribes to changes
  3. Structure Builder views - Complex desk structures with many list items can create multiple listeners
  4. Leaked connections - Sometimes connections don't close properly when navigating away
  5. Development environment - Hot reloading during development can create orphaned listeners

How to fix this:

Immediate steps:

  1. Close unnecessary Studio tabs/windows - Each instance creates listeners
  2. Clear your browser cache and restart - This can help clean up stale connections
  3. Wait 30 minutes - Listener connections have a maximum lifetime of 30 minutes and will eventually expire
  4. Check for other team members - If multiple people have Studio open, you're sharing the listener pool

Longer-term solutions:

  1. Upgrade your plan - A Growth plan gives you 5,000 concurrent listeners
  2. Review your Structure Builder - Simplify complex structures that might be creating excessive listeners
  3. Check for custom plugins - Any custom code using client.listen() could be creating extra connections
  4. Monitor the API request logs in your project dashboard to see listener activity

For development:

  • Use sanity dev instead of multiple Studio instances
  • Be mindful of hot-reloading creating duplicate connections
  • Consider using a separate development dataset if you're frequently hitting limits

The fact that you're seeing it "permanently" at 1,004 suggests you have active connections that aren't closing. The 30-minute connection lifetime should eventually help, but closing Studio tabs is your quickest fix.

If you continue having issues after trying these steps, you might want to reach out to Sanity support to check if there's something unusual with your project's listener connections.

Show original thread
7 replies
Any insight on to what causes this/what the solution is for this? The max listeners error started cropping up at the end of Sunday and rendered the Studio completely unusable by early afternoon yesterday. I continued to check throughout the afternoon and evening without avail.
My solution was to duplicate our Production dataset into another dataset and to point our Studio and Web app to that dataset. I wouldn't want to consider this a long term solution. Any insight on how to prevent this or how to clear it up once the limit has been reached?
Hey Troy! This looks like something that needs to be looked at by a Sanity backend engineer. I’ll pass it along to the team.
projectId: hpttb1hr
dataset: production

🙏
Hi
user G
, are you still seeing the error? From our logs it seems like there are currently 0 active listeners on the project.
If the issue persists or happens again, could you try deleting all documents of type 
system.listener
from your dataset to see if that helps?
Thanks for the insight on 
system.listener
. Not seeing it since moving datasets and removing a 
listenerQuery
call. Is there a better way to clean those up to prevent these issues from occurring?
Our backend should normally take care of cleaning them up, so using 
documentStore.listenQuery
as follows should be alright: https://www.sanity.io/docs/structure-builder-typical-use-cases#980dd321b9db .
Here's another example of using it in a 
useEffect
hook, ensuring you clean up the subscription:
function useHelp(documentId: string) {
  const [help, setHelp] = useState<IHelpMenu | undefined>();
  useEffect(() => {
    const sub = documentStore
      .listenQuery(`*[_id == "${documentId}"][0]`)
      .pipe(tap((val: IHelpMenu | undefined) => setHelp(val)))
      .subscribe();
    return () => sub.unsubscribe();
  }, [documentId]);
  return help;
}
Are you following any of these implementations?
Our backend should normally take care of cleaning them up, so using 
documentStore.listenQuery
as follows should be alright: https://www.sanity.io/docs/structure-builder-typical-use-cases#980dd321b9db .
Here's another example of using it in a 
useEffect
hook, ensuring you clean up the subscription:
function useHelp(documentId: string) {
  const [help, setHelp] = useState<IHelpMenu | undefined>();
  useEffect(() => {
    const sub = documentStore
      .listenQuery(`*[_id == "${documentId}"][0]`)
      .pipe(tap((val: IHelpMenu | undefined) => setHelp(val)))
      .subscribe();
    return () => sub.unsubscribe();
  }, [documentId]);
  return help;
}
Are you following any of these implementations?

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Get started for freeExplore the demo

Was this answer helpful?