Grafana for SaaS and technology companies

Grafana for SaaS and technology companies: what changes when customers depend on uptime

Self-hosted Grafana fits a SaaS team when the team wants its telemetry, dashboards and alert history inside infrastructure it controls, and when it has the people to run a stateful monitoring service. Customers judge a SaaS product by availability and responsiveness, so on-call engineers need one shared view of service health across metrics, logs and traces. Once customer data, SOC 2 scope and multi-tenant signals enter the picture, the stack needs more deliberate design. Metrics from Prometheus or OpenTelemetry, logs from Loki, traces from Tempo and alert rules in Grafana Alerting each hold tenant context, and each can expose it. A tenant ID placed in a Prometheus label multiplies series count for every customer, and a customer name written into a log line or dashboard variable can show one tenant's activity to another tenant's operator.

Licensing matters for a commercial product. Grafana, Loki and Tempo moved from Apache License 2.0 to AGPLv3 on April 20, 2021, according to the Grafana Labs licensing page. Your legal team should confirm what AGPLv3 obligations apply if you modify Grafana or Loki and make them available to users over a network, and whether your internal tooling or plugins fall under the copyleft terms. Grafana Enterprise is offered as a non-AGPL commercial option. It also adds SAML, team sync and SCIM provisioning, which the authentication docs list as Enterprise and Grafana Cloud features, so confirm with Grafana which of those controls your SOC 2 access reviews will depend on before you pick an edition.

Which SaaS requirements shape a Grafana build, and where they come from

This table maps the requirements that most often shape a SaaS Grafana build to the source that creates them and the decision each one forces. Read each row as a question to settle with your compliance lead, counsel and platform team before the build starts, since applicability depends on your markets, contracts and customers.

Requirement	Source	What it means for the Grafana build
Availability and security criteria for monitoring evidence	SOC 2 Trust Services Criteria, common criteria CC6 to CC9 (AICPA)	Dashboards and alert history must show access control, system operations monitoring and change management in a form an assessor can sample. Confirm with your auditor which in-scope criteria your monitoring stack must evidence.
Processor instructions for customer data in telemetry	GDPR Article 28(3)	If logs or traces you monitor contain personal data processed for customers, your processor contract must bind you to documented instructions. Keep Grafana data source queries and log labels within the scope of those instructions.
Security of processing for the monitoring stack	GDPR Article 32	Access to dashboards, data sources and stored credentials is part of your security of processing. Confirm with counsel how your monitoring platform fits the measures described in your records.
NIS2 treatment of cloud and managed service providers	Directive (EU) 2022/2555, Annex I, and Commission Implementing Regulation (EU) 2024/2690	Cloud, data center and managed service providers are treated as high criticality digital infrastructure. Whether your company is in scope depends on size, sector and member state rules, so confirm applicability with counsel before designing risk and incident reporting around Grafana.
Switching rights for customers using data processing services	EU Data Act, Regulation (EU) 2023/2854, Articles 23, 25 and 50	Customers may need to move to another provider or on-premises infrastructure with a two-month maximum notice period. Keep dashboards, alert rules and data sources exportable through provisioning files so that a move does not depend on rebuilding them by hand.
No switching charges from 12 January 2027	EU Data Act, Article 29	From this date providers may not impose switching charges. Ask your counsel whether your service is a data processing service in scope, and confirm what export and migration support your contracts promise.
Article 14 reporting for software placed on the market	Cyber Resilience Act, Regulation (EU) 2024/2847, Articles 14, 69 and 71	If you place software with digital elements on the EU market, reporting obligations have applied since 11 September 2026. Confirm with counsel whether your products, including any internal tooling you ship, are in scope.
Relicensing of the core stack	Grafana Labs licensing page (April 20, 2021 relicensing of Grafana, Loki and Tempo to AGPLv3)	AGPLv3 network-use terms can apply if you modify Grafana and offer it to users over a network, which is common in customer-facing status views. Have counsel review modifications, plugins and whether Grafana Enterprise is needed.

Which Grafana modules and settings SaaS teams configure first

A SaaS team running Grafana for its own services usually settles a small set of foundations before building dashboards. These settings decide whether the instance survives a node failure, who can sign in, whether configuration can be reviewed like code, and how the instance is hardened against exposure.

Configuration database for high availability

Grafana stores its configuration in SQLite by default, but the installation docs state SQLite does not scale for production. For a SaaS deployment, the team must choose MySQL 8.0 or later or PostgreSQL 12 or later before any high availability work begins, and decide who operates that database, its backups and its failover. Confirm the chosen version against your own support policy before standing up the cluster.

Active-active servers behind a load balancer

High availability uses two or more active-active Grafana servers behind a load balancer, all sharing the same external database. Database-backed auth tokens let a user reach any node, so session stickiness is not the main design constraint. The team must decide the node count, the load balancer health checks and how sessions behave during a rolling upgrade, and must test failover before relying on it for customer-facing status views.

Identity provider sign-in and edition choice

Every edition supports LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT. SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. SaaS teams that need SAML sign-in or automated group membership must make that edition decision early, because it changes licensing and how access is removed when staff leave.

Provisioning as code for data sources and alerts

Provisioning loads data sources, dashboards, plugins and alerting resources from YAML or JSON files at startup. Grafana also documents Terraform and Git Sync for as-code management. The decision is which tool is the source of truth, how changes pass review, and whether manual edits in the UI are blocked. Without this, production dashboards drift from the repository and cannot be rebuilt after an incident.

Alert notification settings for HA

In a high availability setup, each Grafana node can evaluate alerts, so one incident may page on-call more than once. The docs note that alerting needs additional configuration to avoid duplicate notifications. Before go-live, the team should define which alert paths route to paging tools, test a deliberate failure to confirm one page per incident, and confirm how Grafana Live limitations affect any live status views.

Security hardening for cookies, CSP and metrics

The hardening guidance recommends secure and SameSite cookies, a Content Security Policy, Trusted Types, hiding the version from unauthenticated users, requiring authentication for the metrics endpoint and domain verification against DNS rebinding. SaaS teams exposing status or shared dashboards to customers should decide which pages are public, test the policy against installed plugins, and confirm that the metrics endpoint is never reachable anonymously.

Service level dashboards and alerts: what SaaS teams build first

Start with a small set of service level indicators (SLIs) tied to the paths customers feel: sign-in, API responses and data ingestion. For each path, pick one measure of success (for example, the share of requests that return a valid response within an agreed latency) and record exactly which requests count. Resist the urge to measure every internal component. A SaaS team that tracks six customer-facing indicators well will page faster and more accurately than one that tracks sixty infrastructure metrics. In Grafana, build one dashboard per service, with the SLI at the top, its trend over the window the business cares about, and the supporting metrics (error rates, saturation, dependency health) beneath it. Keep these dashboards in version control through provisioning so the panels survive a rebuild of the instance.

The targets and error budgets behind those SLIs are business decisions, not engineering defaults. Product, customer success and leadership should agree what reliability each path must deliver and what happens when the budget for a period is spent, such as pausing feature releases. Confirm these values in writing before you encode them in alert rules, and revisit them after the first few review cycles. Grafana Alerting can express burn-rate style rules against those targets, so the question for the team is which windows and thresholds reflect the commitments in your contracts and public status page, not which numbers look good on a dashboard.

Alert rules should page only when a customer is affected or is about to be. Route alerts from Grafana Alerting through notification policies, so that a symptom on a customer-facing SLI goes to the on-call rotation while cause-level warnings go to a channel that is reviewed during working hours. Use silences for planned maintenance and known incidents, and set them with an owner and an expiry. Test each routing path with a sample notification before go-live, and review the paging history every month to remove alerts nobody acted on. If you run more than one Grafana instance or an external Alertmanager, confirm how deduplication works across them before you rely on a single notification.

Self-hosting Grafana versus Grafana Cloud: how the cost compares

With self-hosted open source Grafana, your organization pays for every layer itself. There is no license fee for the Grafana software under the AGPLv3 terms, but the compute, the production database, storage, backups, networking and the engineering time to run them all sit on your books. Setup is largely one-time work (installation, database design, identity integration, provisioning and hardening), while patching, upgrades, backup testing and on-call coverage recur for as long as the instance runs.

Infrastructure: Servers or Kubernetes capacity for at least two active nodes if you need high availability, plus a load balancer.
Database: MySQL 8.0 or later, or PostgreSQL 12 or later, is required for production, so you pay for and operate that database.
Staff time: Upgrades follow a regular cadence (major releases once a year, patch releases at least monthly), and each minor release is supported for 9 months, so someone owns that calendar.
Alerting and on-call: Alerting needs extra configuration in high availability to avoid duplicate notifications, and the on-call rota for Grafana itself is your responsibility.
Cost drivers: User count, data source volume, the number of nodes, and how much engineering time your team has available.

Ask your team to estimate the hours per month for upgrades, backup restore tests and Grafana monitoring, then compare that figure with the cost of a partner-run retainer.

Rolling out Grafana for SaaS and technology companies in phases

This sequence moves a self-hosted Grafana from a single instance into a tenant-aware, highly available, provisioned monitoring stack with on-call alerting, SOC 2 evidence mapping and a separate customer status view. Each phase closes with a check your team can verify before the next one starts.

Map tenant identifiers and label boundaries
Before any dashboard is built, inventory every metric, log and trace source and record which ones carry tenant, customer or account identifiers. Decide which identifiers may appear as labels, which must stay in log bodies or are aggregated away, and which should never reach a dashboard. Your engineering and security leads sign off on this map, because high-cardinality or customer-identifying labels are hard to remove once dashboards and alert rules depend on them. Done means a written label policy exists and each data source has an owner who has confirmed it.
Build the highly available database-backed stack
Install Grafana on the platform you already run, and move configuration off the default SQLite store onto MySQL 8.0 or later or PostgreSQL 12 or later, since the installation documentation says SQLite does not scale for production. Place two or more active-active Grafana servers behind a load balancer that shares that database, with database-backed auth tokens so users can reach any node. Your platform team supplies the database service, load balancer and certificates. Done means a node can be restarted without users noticing and the database backup has been restored once in a test environment.
Configure identity and team boundaries
Connect Grafana to your corporate identity provider using one of the OAuth, LDAP or JWT options available in the open-source edition, and decide whether SAML, team sync or SCIM provisioning is needed, since the authentication documentation places those in Grafana Enterprise and Grafana Cloud. Create folders and teams that mirror who may view internal service dashboards, customer-impacting incident views and production versus staging data. Your identity administrators own group membership, and access reviews should be scheduled against these groups. Done means a test user from each team sees only the folders they are assigned.
Move data sources, dashboards and alert rules into provisioning
Export the data sources, dashboards and alerting resources created so far and convert them into YAML or JSON provisioning files that load at startup, so that a rebuilt node matches the others. Store these files in a Git repository with review, and decide whether further as-code tooling such as Terraform or Git Sync fits your delivery process. Changes made through the user interface should be treated as drafts that must be committed back. Done means a fresh instance built only from the repository matches production dashboards, data sources and alert rules.
Connect alerting to on-call routing and test notifications
Define contact points and notification policies that route each service's alerts to the owning on-call rotation, and set severity labels that your paging tool can act on. Your SRE or on-call lead chooses the paging and chat tools, and the platform team configures the high availability alerting settings so that the two Grafana nodes do not send duplicate notifications. Run a scheduled test alert for each rotation, including a failed-route case where the primary contact point is unavailable. Done means every test page reaches the intended person and the duplicate-notification check passes on both nodes.
Map monitoring outputs to SOC 2 control evidence
Work with your compliance lead to list which SOC 2 criteria your monitoring stack supports, typically the security common criteria covering system operations and availability, and which controls require another system such as a log platform or ticketing tool. For each mapped control, define the evidence to keep: dashboard exports, alert history, access review records and provisioning change history. Your auditor should confirm the mapping, since Grafana does not issue reports and the independent examination determines what is sufficient. Done means each evidence type has a named owner, a retention location and a documented collection routine.
Launch the customer status view on its own boundary
Publish customer-facing status information from a separate Grafana folder, organization or instance that holds only curated, aggregated panels and no internal labels, hostnames or tenant identifiers. Authentication for this view should be isolated from the internal identity groups so that a customer-facing change cannot expose internal dashboards. Your product and support leads approve the panels and the update process. Done means an external test session can see only the approved panels and a review confirms no internal identifiers appear in panel queries or annotations.
Set an upgrade cadence from the release rules
Adopt a written upgrade schedule based on Grafana's published rules: major releases arrive once a year in April or May, minor releases every other month, patch releases at least monthly, with each minor release supported for 9 months and the last minor release of a major version for 15 months. Assign an owner to read release notes, test upgrades in a staging environment built from the provisioning repository, and roll them through the high availability pair one node at a time. Done means the first patch cycle has been completed through staging and the schedule is recorded in your operations runbook.

How Grafana for SaaS and technology companies supports SOC 2 monitoring evidence

A SOC 2 auditor looks for evidence that controls were designed well and operated over time. The cards below show which Grafana outputs can support specific Trust Services Criteria, what each one needs to be credible, and where the evidence has to come from elsewhere. DeployOpen prepares the systems and evidence; independent auditors issue the report.

System operations and alerting

Alert rules, notification routing and dashboards for service health give evidence against CC7, which covers detecting and responding to anomalies in system operations. Keep rule definitions under version control, record who receives each notification, and retain alert history long enough to sample incidents. Check that the alerting design avoids duplicate notifications when you run more than one Grafana server, since the high availability guidance calls this out.

Logical access through identity integration

Signing users in through your corporate identity provider supports CC6 criteria on logical access. Open source Grafana supports LDAP, generic OAuth, Entra ID, Okta and Google OAuth, but SAML, team sync, active sync and SCIM provisioning are limited to Grafana Enterprise and Grafana Cloud. Confirm which of these your auditor expects to see, then map team membership to least-privilege roles and review those mappings on a schedule.

Change management through provisioning

Data sources, dashboards and alert rules defined as files and loaded at startup give CC8 evidence of controlled change. Store those files in Git, require review before merge, and tie each deployment to a commit. Local edits made through the user interface can drift from the repository, so decide whether production allows them and record exceptions.

Availability monitoring and capacity records

Uptime probes, error budgets and capacity panels for your customer-facing services support A1 availability criteria. Keep historical series for the audit period, not only recent data, and document the thresholds that trigger capacity work. The Grafana database itself is a dependency: production needs MySQL or PostgreSQL rather than SQLite, and that choice should appear in your system description.

Monitoring of internal controls

Dashboards that track control performance, such as failed logins, access review completion and patch currency, provide evidence for CC4 monitoring activities. Define each metric, its owner and the response when it breaches a threshold. An auditor will ask whether anyone reviewed these signals, so record the review cadence and the follow-up tickets.

Type 1 design versus Type 2 operation

A Type 1 report describes how controls are designed as of one date, so Grafana configuration, alert rules and access mappings should be documented and frozen for that point. A Type 2 report covers an operating period and tests whether controls worked throughout it, so the evidence must be continuous. DeployOpen prepares systems, controls and evidence for assessment. Independent CPA firms perform the examination and issue the report.

Keeping customer-facing status views apart from internal dashboards

A customer-facing status view should never read from the internal data sources that back your engineering dashboards, and it should never display tenant identifiers, account names, internal hostnames or per-customer error detail. Build it as a separate Grafana folder with its own service account, and give that service account read access only to a curated set of data sources that carry aggregate availability and latency series. Before you design any layout, confirm with your chosen version which public or shared dashboard features it supports, including whether an unauthenticated public link is available, how it is enabled, and what it exposes. Grafana's feature set changes between releases, so test the exact sharing mechanism on a staging instance before it becomes a customer commitment.

Any view shared outside the company needs an explicit authentication decision. If the view is public, the data behind it must already be safe for anyone on the internet to see. If it is limited to customers, route it through your identity provider and map customers to a restricted role, and avoid giving customers accounts on the main instance. Apply the hardening guidance from the Grafana security hardening documentation: require authentication for the metrics endpoint so internal series cannot be scraped from the outside, hide the version from unauthenticated users, and configure domain verification so the instance rejects requests sent through DNS rebinding. Check these settings on the status host specifically, because a separate hostname often sits behind a different proxy and inherits none of the internal configuration.

Customer communication about assurance needs care. A SOC 3 report is a general use report that can be freely distributed, so it is the document to point customers to when they ask about your controls. A SOC 2 report is generally restricted in use, so a status page should not reproduce or summarize its findings for customers who are not entitled to it. Monitoring evidence from your dashboards can support the availability and change management criteria in a SOC 2 examination, but the dashboard itself is an internal control artifact, not a customer deliverable. Ask your SOC 2 auditor, before publishing any status view, which metrics they will sample as evidence and whether any of them should stay internal.

What SaaS teams ask before hiring help with Grafana

What drives the cost of self-hosting Grafana versus using Grafana Cloud?

The main difference is who pays for what. With Grafana Cloud, you pay Grafana Labs a platform fee and usage charges, and the pricing page lists a free tier, a Pro tier starting at a 19 US dollar monthly platform fee plus usage, and an Enterprise tier with a minimum commitment of 25,000 US dollars per year. Self-hosting shifts those costs to your cloud accounts, your engineers' time for upgrades, backups, high availability and alerting, and the database you must run. Ask any quote to separate one-time build work from recurring hosting, patching and on-call support, and to model log, metric and trace volume, since usage drives the bill in both models.

How long does a Grafana implementation take and what sets the timeline?

The timeline depends on how many data sources you connect, how many teams need dashboards and alerts, and whether you need high availability. Grafana's installation docs say small deployments under 25 concurrent users fit on 2 cores and 2 to 4 GB of RAM, but production use needs MySQL 8.0 or later or PostgreSQL 12 or later instead of SQLite. Highly available setups run two or more active-active servers behind a load balancer, which adds configuration and testing. Ask for a written scope with defined deliverables before accepting a timeline, since most engagements are fixed-scope and agreed in writing before work starts.

Can our in-house team build and run Grafana without outside help?

Often yes, if you have engineers who already run databases, reverse proxies, identity providers and infrastructure as code. Grafana's packages, Docker images and Helm charts make the first install straightforward. The harder parts are high availability, where alerting needs extra configuration to avoid duplicate notifications and Grafana Live has limitations, plus provisioning dashboards and data sources as code, and keeping up with releases. Grafana's upgrade guidance describes major releases once a year and patch releases at least monthly, so someone must own that cycle. Consider a partner for the build and handover, and keep operations in-house if your team has capacity.

What does the work need from our engineers and security team?

Plan for named engineers in platform, identity, networking and security from the start. Platform engineers provide compute, the database, load balancing, DNS and storage. Identity staff connect your provider for sign-in and group mapping. Security staff review cookie settings, the Content Security Policy, authentication on the metrics endpoint, and domain verification, which the security hardening docs recommend. Your team also decides who can see which dashboards and which data sources, and approves outbound connections. Confirm access, change windows and approval steps in the scope, because delays in these reviews are a common source of schedule slip.

Does SAML single sign-on require Grafana Enterprise?

Yes, SAML is available only in Grafana Enterprise and Grafana Cloud, according to the Grafana authentication docs. The open-source edition supports LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth, auth proxy and JWT. Team sync, active sync and SCIM provisioning are also limited to Enterprise and Cloud. If your identity provider only offers SAML to applications, you will need either an Enterprise license or an OIDC route through your provider. Confirm current edition entitlements with Grafana Labs before you commit to a design.

What does SOC 2 need from our monitoring stack?

SOC 2 examinations use the AICPA 2017 Trust Services Criteria, and the common criteria CC1 to CC9 apply to every SOC 2. Monitoring supports several of them, particularly the system operations and risk mitigation areas, by showing that availability and error conditions are watched and alerted on. Grafana can provide dashboards and alert history, but it does not produce the controls or the report. DeployOpen prepares systems and evidence for assessments but does not issue audit reports; a licensed CPA firm does. A SOC 2 Type 1 report covers control design at a date, and a Type 2 adds operating effectiveness over a period, so retain alert and access records continuously. Ask your auditor which evidence they accept.

Does the AGPLv3 license affect a SaaS company running modified Grafana?

Possibly, and this is a question for your counsel. On April 20, 2021, Grafana Labs relicensed Grafana, Loki and Tempo from Apache License 2.0 to AGPLv3, and the licensing page says plugins, SDKs and agent software keep other licenses. AGPLv3 includes network-use obligations that can require offering source code to users who interact with a modified version over a network. Whether that applies to your internal dashboards, customer-facing views or modified plugins depends on how you deploy and distribute the code. Ask counsel to review your architecture, and confirm terms with Grafana Labs, including whether Enterprise changes your obligations.

Which parts of a Grafana engagement does DeployOpen handle?

DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. For Grafana, that can cover installation, database and high availability design, identity integration, provisioning as code, alert routing and handover documentation. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. DeployOpen does not publish a price list, so a quote follows from the written scope.

How DeployOpen scopes and delivers a SaaS Grafana implementation

DeployOpen plans, implements, hardens, documents and supports self-hosted Grafana inside your own cloud accounts, data centers or restricted networks. For SaaS and technology companies, the work starts with the services, alerts and status views your teams already depend on, and every step is agreed in writing before build begins.

How we scope

Inventory the services, customer-facing SLOs and data sources the dashboards and alerts must cover
Confirm the database choice, expected concurrent users and whether high availability is required
Agree which on-call tools, notification channels and escalation paths alerts will route into
Define which SOC 2 monitoring evidence the stack must produce, and which controls it will not cover
Compare self-hosting costs against Grafana Cloud tiers using your own usage and staffing figures

How we build

Deploy Grafana on the platform you run, with the database, reverse proxy and TLS configured as scoped
Configure identity sign-in and role mapping, using the authentication options your edition supports
Define data sources, dashboards and alert rules as provisioning files kept in version control
Set up alert routing with high availability settings that avoid duplicate pages across nodes
Test dashboards, alert paths and failover against planned scenarios before cutover

How we hand over

Deliver the written configuration, provisioning repository and deployment runbook for your team
Document the access model, owners for each dashboard and the review process for changes
Record how status views are published and which data is shown to customers and which is not
Provide upgrade, patching and backup procedures sized to your release and support schedule
Train the operators who will maintain alerts and respond to Grafana platform issues

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover
Review new Grafana releases against your deployment and plan upgrades before support ends
Keep alert rules, data sources and provisioning files current as your services change
Confirm with your auditor which monitoring evidence they will accept before the examination period
Agree response expectations and service terms in the written retainer, not in general statements

Grafana for SaaS and technology companies