Upgrading from next14 to 15 fixed it.

Hmm no it didn't, I wasn't looking in the right place

Well, that's not good 😄

With next15

All functions on Vercel are ISR functions, even static pages have the opportunity to be revalidated even if you never do. The important thing to note is what the build output says, not the resources tab.

In the build output those pages should be marked as static via the non-filled in circle.

The builds says static, the ressources tab shows isr

Yeah, then everything is working as expected.

It doesn't sounds like it "works as expected" to me, I really don't see the point of converting static assets to isr functions that requires a runtime.

Looks like a step backwards to me, and ressembles a billing trick more than anything.

The ISR function is the function that runs at build-time to generate your static page, since the build output shows that page as static, it will NEVER invoke the ISR function at runtime, only during builds to generate the static HTML.

That would make sense!

But I do get a bunch of CPU and function invocation billing

i think the point is if you call a server action or revalidatePath from any of these pages, it will need a runtime from the hosting platform to run those server action. so every page will get a runtime to be used when necessary. vercel can't know that you don't use any server actions.

to declare to vercel that you absolutely do not use any server actions, output: 'export' is the way to go.

to declare to vercel that you absolutely do not use any server actions, output: 'export' is the way to go.

That negates one of the main selling point of next.js

Your runtime logs show function invocations for these static routes, or edge cache prerenders?

which is?

@Plague Indeed, you seem to be right

Great then, and feels better

The "usage" I am seeing seems to be related to the first generation then

Still feels ugly that "ISR Reads" is being billed

This one too

Well, all your static content needs to be served from somewhere, in this case it's the ISR cache

output:export builds doesn't consume ISR usage

Right, for the reason Joulev mentioned.

I'd argue that the expected behaviour is this on all routes, except when the user actually uses that

In that case your static content is served directly from Vercel's Edge CDN network

Which could be the case too with pages that don't actually require any compute to be rendered, and are actually pre-generated at build time

Thanks for your answers, this feels off, I'll just throw this in a container and call it a day

100%, but as Joulev mentioned, Vercel can't know if you use a server action via something like a form, so in that case it has to throw it on an ISR function to run at build-time to generate the page and to be ready to run at runtime IF you use a server action.

That compute needs to run somewhere, the alternative is a non-working form. I hope that makes sense.

It does, but that really looks like an implementation detail and a design decision, this is what feels off

(And thanks for your answers!)

No problem, and yeah I get the confusion/frustration it is indeed a this or that situation

I think that if you need pure SPA-like features. you don't need the complexity that next adds

Yes, this is 100% true. Next.js is a Full-Stack server-centric framework.

What also feels like a bummer is that this setup is going to be slower than just serving dumb static assets

So it's a bit surprising that it works that way

It shouldn't be, the static pre-generated output of the ISR function is thrown on the edge network, cached regionally and durably on the ISR cache.

Meaning frequently accessed content will be served from the regional edge network, while others will be from the global edge network.

It'll only invoke the actual ISR function for compute (i.e. a server action)

I see, thank you, I thought it was more involved than that.

Then perhaps it's more how the billing is structured that bothers me. I am pretty new to these kind of "hosted" platforms and it feels that the individual usage items are a bit artificial. I don't mind paying, really (and did take a pro plan), but I'm really starting to think that the approach I take with some other projects (just a redundant container with next in standalone mode) may make more sense, unfortunately, vercel felt pretty nice but it seems that I'll bankrupt myself with any traffic 😄

Understandable, admittedly, Vercel's pricing model is the biggest barrier of entry compared to other hosting platforms, it can be a lot to digest as they are very granular with everything.

This has some benefits for the consumer, but it does make the entire process a lot more of a headache, so I don't blame you at all for feeling this way.

What's especially surprising is that when I raised a support ticket, their reply was "use output: export" too, but then, why anyone would use vercel instead of free and unlimited cloudflare pages or similarly extremely cheap offerings?

Am I missing anything obvious? 😄

I'm not sure. For a fully static website though, Next.js is probably overkill.

Seems like this thing really isn't for me, now I am getting randomly failing builds even with output:export, local builds succeeds, I'll just throw things in a container then 🙁 (same commit hash where a previous build succeeded)