GTM Server-Side Tracking Cost Calculator 2026
Reviewed by The Architect · CreatorOpsMatrix · Updated October 1, 2026 · Pricing checked against current Stape, Google Cloud and Make documentationHow much does server-side GTM cost? There is no single number. Stape uses fixed request tiers, Google Cloud Run is usage- and configuration-dependent, and implementation labor depends on the architecture and your team. This GTM server-side tracking cost calculator lets you enter your actual request volume, Cloud Run server count, labor assumptions and Make credit usage instead of relying on generic cost estimates.
Important: the old version of this page treated request volume as though it translated directly into Google Cloud and Make costs. That is not reliable. Cloud Run costs depend on the selected billing model, CPU, memory, concurrency, instances, region and networking. Make costs depend on the actual modules and operations in your scenario. The calculator below exposes those variables instead of hiding them behind a fixed formula.
Server-Side Tracking Cost Calculator
October 2026 modelYour modeled cost
| Architecture | Monthly modeled cost | Setup labor | 1-year total | 5-year total |
|---|---|---|---|---|
| Stape | $17.00 | $0.00 | $204.00 | $1,020.00 |
| Google Cloud Run | $90.00 | $0.00 | $1,080.00 | $5,400.00 |
| Make.com | $12.00 | $0.00 | $144.00 | $720.00 |
Make.com credit model
Make is useful when you want webhook-driven automation without operating an sGTM container, but it is not a drop-in numerical equivalent of server-side GTM. The right input is your actual monthly Make credit consumption.
What actually determines GTM server-side tracking cost?
Server-side GTM cost is driven by more than the hosting subscription. The architecture, request volume, instance configuration, implementation work, monitoring requirements and any additional data-processing services all affect the final budget.
That is why two websites with similar traffic can have very different implementation costs. A simple measurement setup and a multi-destination architecture with custom transformations, consent handling, first-party cookie logic and several advertising endpoints are not equivalent projects.
The useful number is your own operating model. Use published vendor pricing for the infrastructure component, then add the labor you actually expect to spend. Do not turn a generic “typical setup takes X hours” claim into a budget without verifying the scope.
Stape pricing: the cleanest fixed-tier model
Stape currently publishes separate sGTM hosting tiers based on monthly requests. The published levels are Free up to 10K requests, Pro at $17/month for up to 500K, Business at $83/month for up to 5M, and Enterprise at $167/month for up to 20M. Annual billing is also published at $200, $1,000 and $2,000 respectively for those paid tiers.
| Stape tier | Request limit | Monthly list price | Published annual price |
|---|---|---|---|
| Free | 10K requests | $0 | $0 |
| Pro | 500K requests | $17/mo | $200/year |
| Business | 5M requests | $83/mo | $1,000/year |
| Enterprise | 20M requests | $167/mo | $2,000/year |
Above 20M requests, the published page moves to a custom tier rather than exposing a universal flat price. The calculator therefore does not invent a higher Stape number.
Stape’s request counter matters
Stape says a request is counted when a request is sent to the server container and specifically notes that script loads such as gtm.js, analytics.js and gtag.js count. Its documentation offers pageviews × 10 as a rough estimate, but your actual container traffic is the better input when available.
What happens when you exceed the Stape limit?
Stape’s current documentation says paid containers are paused after reaching 110% of their monthly request limit unless the account is automatically upgraded. Pro and Pro+ do not receive the 30-day grace period. Business and higher receive a one-time 30-day grace period when the overlimit happens for the first time.
Stape also provides an auto-upgrade option that moves the container to the next tier and charges the new plan. That makes the operational choice straightforward: accept the possibility of a pause, provision more capacity, or enable automatic upgrading and accept the associated billing increase.
Google Cloud Run: why the old fixed formula was misleading
Cloud Run is a usage-based cloud platform rather than a single server-side-GTM price. Google’s current GTM server-side setup guide uses a reference configuration of approximately $45 per server per month and discusses multiple servers for production resilience. Actual Cloud Run bills depend on the deployment configuration and selected billing model.
Google also publishes general Cloud Run pricing based on CPU, memory and request usage. That pricing page currently lists a 2-million-request free tier for request-based billing and a $0.40-per-million request rate at the standard level, but those figures should not be turned into the entire cost of a GTM server-side deployment. CPU, memory, instance configuration, scaling and networking still matter.
That is why this calculator asks for a server count. It is using Google’s documented sGTM reference-server model rather than pretending the entire deployment can be reduced to “requests × $0.40.”
Make.com as a webhook automation alternative
A Make scenario can receive webhooks, transform data and call external APIs, making it useful for selected server-to-server automation patterns. It can therefore overlap with part of a tracking architecture, but it should not automatically be described as a complete replacement for every capability of a GTM server-side container.
Make’s current billing unit is the credit. Most ordinary module actions consume one credit, while some features consume more. A single scenario run can therefore consume multiple credits depending on its structure, branches, searches and downstream actions.
Because of that, the calculator deliberately asks for monthly Make credits rather than pretending that one GTM request equals one Make credit.
Current Make entry pricing
| Plan | Published entry level | Monthly price | Useful distinction |
|---|---|---|---|
| Free | 1,000 credits | $0 | Basic automation use |
| Core | 10,000 credits | $12/mo | Make API and expanded controls |
| Pro | 10,000 credits | $21/mo | Priority execution and advanced tools |
| Teams | 10,000 credits | $38/mo | Team roles and shared scenario features |
Make exposes higher credit tiers through its pricing selector. The calculator intentionally does not fabricate those larger-tier prices from a linear formula because the price changes with the selected tier.
What the old calculator got wrong
- It treated 50–120 setup hours as a universal benchmark without a defensible source.
- It claimed a $80,000–$154,000 five-year cost without establishing the maintenance workload behind those figures.
- It used an obsolete Make operation price of $10.59 and converted GTM requests into Make operations using an arbitrary 2% event formula.
- It described Cloud Run as roughly $65/month plus request charges, which is not a reliable representation of Google’s current server-side GTM reference deployment.
- It declared an architecture the “cheapest option” even though its Make cost formula was based on unsupported assumptions.
- It presented the Smart Pause behavior without distinguishing the current Pro rule from the one-time Business/Enterprise grace period and auto-upgrade option.
How to use the calculator correctly
- Use an actual Stape/server-container request figure when possible. If you only know pageviews, pageviews × 10 is a rough starting estimate.
- Select monthly or annual Stape pricing based on how you expect to pay.
- Enter the number of Cloud Run servers you actually intend to keep running. Treat Google’s $45/server figure as a reference, not a quote.
- Add only the setup hours you genuinely expect to spend. The calculator no longer manufactures an “industry standard” labor number.
- For Make, use the credit consumption from the scenario itself rather than converting sGTM requests into an assumed number of credits.
Which architecture fits which situation?
| Architecture | Core cost model | Infrastructure responsibility | Best interpreted as |
|---|---|---|---|
| Stape | Published request tiers | Managed hosting layer | Managed sGTM hosting |
| Google Cloud Run | Resources, instances and traffic | Your cloud deployment | Self-managed sGTM infrastructure |
| Make.com | Credits and workflow actions | Make manages the platform; you manage the scenario | Webhook/API automation alternative, not a 1:1 sGTM clone |
Frequently Asked Questions
Is Stape cheaper than Google Cloud Run?
That depends on the Cloud Run configuration, number of servers and operating requirements. Stape publishes fixed request tiers, while Google Cloud Run is usage- and configuration-dependent. This calculator therefore shows both models rather than declaring a universal winner.
Does Stape really pause tracking when usage goes over the limit?
Stape currently documents a 110% threshold for paid products. Pro and Pro+ pause at that threshold. Business and higher receive a one-time 30-day grace period for the first overlimit event, and auto-upgrade can move a container to the next tier instead of pausing it.
How should I estimate Stape requests?
Use your actual server-container request data when possible. Stape’s documentation gives pageviews × 10 as a simplified estimate, but real request volume depends on the implementation and the requests sent to the container.
Does Google Cloud Run cost $0.40 per million requests for server-side GTM?
Google does publish a $0.40-per-million request rate at the standard Cloud Run pricing level, with a 2-million-request free tier under request-based billing. But that is not the whole cost of a server-side GTM deployment. CPU, memory, instance configuration and the chosen billing model can dominate the total.
Can Make.com replace server-side GTM?
Make can handle webhook reception, transformations and API routing for specific tracking workflows. That does not mean it reproduces every GTM server-side feature, client, tag, consent mechanism or routing pattern. Treat it as an automation architecture option for appropriate workloads rather than an automatic one-for-one replacement.
Why doesn’t this calculator use a fixed setup-hours benchmark?
Setup effort depends heavily on the implementation. A basic deployment can be very different from a multi-destination architecture with custom transformations, consent requirements, first-party cookie configuration, debugging and several advertising platforms. Enter your own estimate rather than relying on an unsupported universal range.
Ready to compare the tracking stack around the hosting cost?
The infrastructure bill is only one part of the decision. See how browser and server-side tracking differ, then inspect the implementation details behind event routing, deduplication and attribution.
Evaluate the platforms directly
These links currently point to the providers’ official pricing pages so the page never invents or obscures a referral destination. Replace them with your approved partner URLs when available.