Is there some way to limit the size that is allowed for Confluence page creation?

[david cockrell]

Dear Confluence Experts,

First, to give some background to my concerns and my question... 

I am a Confluence System Admin of a very large Confluence instance. 

We see growing number of users manipulating the content via API using personal tokens and even via non-authorized MCP servers.

Should I be concerned? 

What risks should I be aware of, what potential impact and are there any suggestions to mitigate? 

Recently we realized that occasionally the Content queue got stuck for quite some time
when analyzing, we found that it was due to very large pages that were auto-created via via personal token

To protect the system from such incidents and guaranty stability and performance, I wonder is there some way to limit the size that is allowed for Confluence page creation 

[Arkadiusz Wroblewski]

Hello @david cockrell 

David, I’d definitely share your concern. In a large Data Center environment, uncontrolled scripts or MCP-style tools can really hammer your indexing queue and bloat the database before you even realize what’s happening. It’s not just the API usage itself that's the problem; it’s the potential for indexing backlogs and hard-to-govern data exposure.

To answer your specific question, there actually isn't a direct Confluence setting to limit the size of a page body. You have the attachment size limit, but that won't touch the actual text content of a page. There is a technical "sledgehammer" you could use—the -Datlassian.rest.request.maxsize system property—but I’d be extremely cautious with it. Since it’s a global REST limit, lowering it to stop a rogue script could easily break legitimate integrations, marketplace apps, or even standard site imports.

A much safer and more effective route is to lean on native Rate Limiting. It’s designed specifically to protect DC instances from REST-heavy automations that go off the rails. Beyond that, I’d look at tightening your Personal Access Token (PAT) governance. Forcing expiry dates, limiting the number of tokens per user, and requiring reviewed service accounts for any "official" automation will give you way more control than a single page-size setting ever could.

If users are connecting external tools via PATs, you're also looking at a significant security and governance topic, as those tools are acting with that user's full permissions. Monitoring your access logs to identify high-volume REST users is usually the best way to catch these issues before they impact the rest of the team. Use rate limiting to protect the instance and PAT governance to protect the data.