.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Count two numbers before you read on: how many active metric series you produce, and how many gigabytes of logs you ingest in a month. Those decide this, and almost nothing else does.
The choice is rarely about features. The dashboards are the same dashboards, the alerting is the same alerting, and the plugin catalogue overlaps heavily. Dashboard count, user count and how many servers you watch move the answer far less than the two numbers above.
What Grafana Cloud's free tier includes
Checked against the Grafana pricing page on 26 August 2026, the free plan listed 10,000 active metric series, 50 GB of logs, 50 GB of traces and 50 GB of profiles ingested a month, all at 14 days of retention, plus a Kubernetes monitoring allowance and a cap of three active users on the visualisation side. Grafana Labs revises these, so treat the shape as stable and the figures as a snapshot.
The free tier being permanent rather than a two week trial is unusual enough that people keep asking where the catch is. I have not found one. It is a funnel and it works, because the paid tier starts more or less exactly where a hobby project stops being a hobby project.
Two of those limits do the work. Ten thousand active series sounds large and is consumed faster than you would guess. A single Linux host running node_exporter produces something in the region of 500 to 1,000 series depending on how many filesystems and interfaces it has, so ten hosts of plain infrastructure metrics puts you at or near the ceiling before you have instrumented a single application. Add a cAdvisor or a Postgres exporter and you are over.
Three active users is the other one. It is fine for a small team and it is a hard stop the moment you want the whole engineering group looking at dashboards, since an active user is anyone who signs in during the billing month.
How Grafana Cloud bills past the free tier
The paid self-serve tier at the time of checking: a $19 monthly platform fee plus usage, metrics at $6.50 per 1,000 series with 13 months of retention, logs and traces split into per-GB charges for processing, writing and retaining, and $8 per active user for Grafana visualisation. Check the current page rather than trusting a figure in an article.
The shape is what matters. Your bill tracks series cardinality and ingest volume, and both of those grow with what your code emits rather than with how many machines you own. That is a different curve from per-host pricing, which is how Datadog bills and which Grafana versus Datadog takes apart properly. The curve cuts both ways. Four beefy servers producing modest telemetry are cheap. Forty small containers each emitting a histogram labelled by request path are not.
The failure mode to watch for is a deploy that adds a label. One metric with a customer ID or a URL path attached can multiply your series count overnight, and the first you hear of it is a usage alert or an invoice. Set a billing alert on day one, before you need it.
What self-hosting costs, line by line
The line items, flatly. A server: Grafana's own documentation puts the minimum recommended memory at 512 MB with one CPU core, which is an evaluation floor, and two to four gigabytes is the number if Prometheus and Loki share the box. Disk, sized from your retention window. An application database: the installation docs list SQLite, MySQL 8.0 and PostgreSQL 12 as the supported options, note that SQLite is not recommended for production and require MySQL or PostgreSQL for high availability.
Then the recurring costs. Grafana ships a minor release every other month, so an upgrade cadence exists and skipping it accumulates risk. Backups of /var/lib/grafana need to be real backups you have restored once. TLS certificates renew. Somebody watches the watcher, which in practice means a heartbeat alert delivered through a channel that does not depend on your own stack.
Call it three to five hours to build, an hour a month of care, plus half a day two or three times a year when an upgrade surprises you. Installing Grafana on an Ubuntu VPS has the build half, and it is genuinely an afternoon rather than a project. The hour a month is the part nobody puts in the spreadsheet.
Where the crossover sits
Count your active series. Under 10,000 and expecting to stay there, Cloud's free tier is free and a VPS is not, so self-hosting has to win on something other than cost. Between 10,000 and roughly 100,000 series, the paid Cloud tier is a real monthly number that a small server would absorb without noticing, and this band is where most switching happens. Above a few hundred thousand series, self-hosting is dramatically cheaper and the only question is who runs it.
Logs skew this harder than metrics, because volume is easy to underestimate. Fifty gigabytes a month is about 1.6 GB a day, which a handful of chatty applications with debug logging left on will exceed on a quiet Tuesday. If you ship application logs at all, model your daily volume before choosing.
Dashboard count, alert rule count, number of data sources and number of servers monitored are not billed at all. None of them belong in the calculation.
My own bias, stated so you can discount it: I self-host earlier than that arithmetic suggests, because of the migration rather than the money. Moving a year of history under pressure is genuinely unpleasant, so I would rather run a small server for six months I did not strictly need than do it in a hurry.
What you give up by self-hosting
You give up managed Mimir, Loki and Tempo. Running long-term metrics storage yourself is a real skill and running it badly is worse than not having it. You give up the incident and on-call tooling that comes with the platform, which is otherwise a separate product you pay for. You give up synthetic monitoring from locations you do not own, and you give up not doing upgrades.
You also give up someone else's uptime. A self-hosted stack that shares a region or a provider with the systems it monitors will go dark exactly when you need it. Putting the monitoring host somewhere else and adding a dead man's switch solves it, and remembering to solve it is the hard part.
What you gain by self-hosting
Your data stays where you put it. For teams with GDPR obligations or a contract that names a jurisdiction, this is frequently the entire argument. Grafana Cloud's region is fixed at stack creation, and the regional availability documentation lists EU regions in Germany, Ireland, Belgium, the Netherlands, Sweden, Switzerland and the UK. It states plainly that Grafana does not support changing the region of an existing stack. Choose wrong and the fix is a new stack.
You get a predictable bill. One server costs what one server costs, and a bad label in a deploy costs you RAM instead of money. That predictability is worth more than it sounds when you are the person who has to explain a variance.
You get full plugin freedom, including unsigned plugins. Self-hosted Grafana lets you allow specific unsigned plugin IDs through allow_loading_unsigned_plugins, which matters if you have written an internal data source for a system nobody else has. On a managed instance, that door is closed.
And you get the API surface without seat pressure. Unlimited users, unlimited service accounts, no active-user counting, which makes automation cheap. Provisioning dashboards and alerts through the API is covered in Grafana API tokens and service accounts. None of it counts against a seat allowance.
SMTP configuration on Cloud versus self-hosted
Grafana Cloud sends alert email for you. The email contact point documentation states it directly: in Grafana Cloud, SMTP configuration is not required. You add an address and the mail arrives.
Self-hosted Grafana has no mail relay. The [smtp] section ships entirely commented out with enabled = false and host = localhost:25, so a fresh instance sends nothing and reports SMTP not configured when you test a contact point. You need an authenticated relay on port 587 with STARTTLS or 465 with implicit TLS, because outbound port 25 is blocked by default on most hosting networks to protect address reputation. The Grafana SMTP settings reference has the full configuration, including the leading semicolon that keeps the whole block inert. Budget an hour for this on a migration off Cloud, and do it before you switch your alert routing.
Hybrid setups: self-hosted Grafana with Cloud storage
Self-host Grafana, use Cloud for storage. Run your own Grafana instance for dashboards and access control, and remote-write metrics to Grafana Cloud so you do not operate Mimir. You keep unlimited users and unsigned plugins locally while somebody else handles retention and scaling. This is a good fit when your objection to Cloud is the per-user billing.
Use Cloud Grafana, keep the data at home. The reverse arrangement puts the managed Grafana in front of data sources on your own network reached through a private connection, so telemetry stays on your infrastructure and only query results cross the boundary. Useful when you want the managed UI and cannot ship raw logs off site.
Run both instances for the migration window. Whichever direction you are moving, run the old and the new in parallel for a month with both alerting. Alert rules you forgot to port are invisible until something fails to fire, and comparing what fired where is the only reliable way to find them.
Which one to pick: Cloud or self-hosted
Grafana Cloud is the obvious answer if you are under the free tier limits and expect to stay there, if nobody on the team wants to own a server or if you need traces and profiles without building the pipelines for them. It is also right when you would otherwise put the monitoring stack in the same failure domain as production.
Setting monitoring up for a team with nobody who enjoys servers, I put it on Cloud and do not agonise about it. The alternative is a machine nobody owns, which quietly stops getting patched in month four and then becomes an incident of its own.
Self-hosting on a VPS is the answer when your series count is well past the free tier and climbing, when log volume is your dominant cost, when data residency is contractual rather than preferred or when you need more than three people looking at dashboards without paying per active user. It is also right when you already run Linux servers competently, because then the marginal effort is small and the marginal cost is one more machine. Other tools worth weighing at that point are in the Grafana alternatives roundup, since a few of them fold storage and display into one process and remove the question.
One thing I have never got a clean answer on is how the active-user count treats automation on the visualisation side. My reading is that service accounts do not count towards it. I have not tested that hard enough to promise it, so if your plan depends on the answer, ask before you build on it.
The operational detail of running your own instance well sits in the complete Grafana guide. Everything else is the two numbers at the top of this page.
