32 MB Passes, 4 MB Fails: What the Power Pages Server Logic Memory Limit Actually Does

The limit isn't documented

Microsoft Learn documents a timeout for Server Logic through ServerLogic/TimeoutInSeconds. It doesn't list a memory limit today.

It used to. An earlier version of the Server Logic overview listed ServerLogic/MaxMemoryUsageInBytes with "Maximum memory per function: 10 MB". That row was removed in November 2025 without an explanation.

So I measured it.

How to measure something you can't read

Server Logic has no heap API. You can only find the limit from the outside: allocate memory until the call fails, then narrow it down with a binary search.

The cost of any step is then a simple subtraction: how much extra memory fits without that step, minus how much fits with it.

I got three things wrong before the numbers made sense. You'd probably hit the same three:

1. "x".repeat(n) allocates almost nothing. The engine keeps a compact reference until you read the string. In a local test, 20 MB of text cost 0.01 MB. Read one character with charCodeAt and it costs the full 20 MB.
2. Without a pause, you measure the wrong limit. More on that in the next section.
3. The last log line isn't a reliable signal. Use the HTTP status and the trace of the request.

The probe and the test runner are available for download below.

The check is periodic

This is the finding that matters most. I allocated 8 MB, well above the limit, and let the script keep running for a set time. Each row is ten calls:

The limit only applies when a check runs, and that seems to happen roughly every 100 to 200 ms. A script that goes over the limit and finishes quickly is never caught.

Without any pause, 32 MB passed three out of three times. At 64 MB, one of three passed. Everything above failed.

I don't know the implementation. The error text matches the wording in the ClearScript project, and an issue there describes exactly this: the heap size is sampled periodically, so a sudden spike between samples can go undetected. That fits what I measured, but that Power Pages uses ClearScript is my inference, not a statement from Microsoft.

What the limit is

So every measurement needs a pause. I used 300 ms. These amounts fit:

There are two things to take from this:

• There's no single number. The same limit allows 1.7 MB or 4.8 MB, depending on how the memory is used.
• One special character can double a string. The engine stores a string with even one character outside Latin-1 at two bytes per character. A single bullet point in a description is enough.

Parsed objects are the most expensive. Under 1 MB of JSON fills the limit if you keep it as objects.

Where the memory goes in one call

Real code rarely holds ballast. It holds the same data several times.

A Custom API response reaches Server Logic as a string with the actual result nested inside, as strings within strings. I replayed that shape with 266 KB of content. This is the memory in use at each step:

266 KB of JSON already reaches the limit. This doesn't mean a 266 KB call always fails. It means a check at the wrong moment would catch it.

That shows when I raise the payload size. The "with pause" column uses five calls with a 300 ms pause, the other two use ten calls each:

The second column is the trap. 856 KB looks completely fine in a quick test, then fails as soon as anything makes the script run longer.

Logging a payload is a timing problem

The right column already shows it. Here is a direct comparison at 483 KB of content, with 80 calls each, in alternation:

Building the string isn't what breaks it. The log call is. It adds about 350 ms while the entire payload stays in memory, so a check is far more likely to land in that window.

There's one more catch. In these failures, the trace is often missing, probably because the log is too large for it. You lose the error message exactly when you need it.

Never log a full payload outside of a short debugging session. And if a failure has no trace, check whether your own log is the reason.

Logging isn't the only cause, though. Without any logging, the larger payloads above still fail as soon as a check lands. Removing logs buys you stability, not capacity.

MaxMemoryUsageInBytes still works

I set the undocumented setting to three values and measured each one:

This table tells me two things:

• The default still seems to be 10 MB. Not setting it and setting 10 MB give identical results. The old documentation was right about the number.
• 10 MB doesn't mean 10 MB is available. About a third of it can actually hold your data.

The setting works immediately. I still wouldn't build on it. It's gone from the documentation, so it may change without notice, and I haven't tested concurrent load. Use it as an emergency measure, and ask Microsoft through a support ticket before you rely on it in production.

The real fix is less data

On a real project, the results page used about 13 % of the data it loaded. Most of the payload was attributes that only one detail page displayed. Filtering the related lists in the API shrank one response from over 500 KB to about 20 KB, and the failures on the detail page were gone.

Before you tune anything, check three things:

• What does the page actually use? List the fields your front end reads, then compare that with the response.
• How many calls does one page make? That project's filtered search made a second request that loaded the complete catalog.
• Is your DEV data realistic? A failing page that works on DEV usually has less data, not better code.

The browser isn't your bottleneck. In Chrome, parsed JSON took about 1.3 times its own size in my test, and a browser tab has far more room than 3 MB. The tight limit is on the server.

A budget you can use

With default settings, on my measurements:

• Up to about 250 KB of JSON per call: You have room, even if a check lands at the worst moment. This one is my estimate, since 266 KB already reached the limit at the peak.
• Up to about 450 KB: It works, but it depends on timing, and a slow response can push it over.
• Above about 500 KB: It fails as soon as a check lands.

Measure your own response sizes, and work out how much one record costs you. That number tells you how far your data can grow. Your limits may differ from mine, so run the probe on your own environment.

Try it yourself

Download the probe and the runner:

• memory-probe.js: Server Logic with ballast, a replay path and checkpoints. Create it as blogtest-memory-probe.
• memory-probe-runner.console.js: the browser console script that runs the series. Paste it on your portal and read window.probeResults when it's done.

Use a development environment only. The probe deliberately pushes the limit.

I measured this on a trial environment in the US region in November 2026. Numbers on other environments may differ: on a second tenant, the text limit was lower while the object limit was identical. If you run it, I'd like to know what you get.

Sources

• Server logic overview, Microsoft Learn
• Author server logic, limitations, Microsoft Learn
• Server objects, Microsoft Learn
• MicrosoftDocs/power-pages-docs, commit b125d92b: adds the setting
• MicrosoftDocs/power-pages-docs, commit 29432970: removes it
• ClearScript issue 84 and issue 571