Grafana for healthcare: why self-hosting fits clinical monitoring
Hospital IT leaders and health software providers need visibility into EHR and clinical systems, but they often cannot send operational data to a third-party cloud without a long review. Self-hosted Grafana keeps dashboards, data sources and stored configuration inside the organization's own environment, which is why it is a common fit for this sector. This page covers how to run Grafana in that setting and the decisions the sector forces: what dashboards display, which labels and fields carry data, how long telemetry is kept, and how staff sign in. It also explains why the monitoring stack has to be planned against the HIPAA Security Rule even though HIPAA does not certify any product or stack.
The HIPAA Security Rule applies to covered entities and their business associates for the electronic protected health information they handle. A monitoring platform that queries clinical databases, logs or interface engines may touch that information, so it belongs in the risk analysis and access design. There is no HIPAA certification for Grafana or any other tool. HHS states that no Security Rule standard requires certification, so the useful question is what your own evidence shows: who can see which panels, how access is reviewed, and whether the platform is patched and backed up. Confirm with your privacy and security officers which of your monitoring data counts as ePHI before you design the data sources.
The sections that follow take these decisions in order. Start by deciding which systems Grafana will query and whether any dashboard or alert message can carry patient identifiers, because that choice sets the access model for everything else. Then confirm the identity and authorization path, since SAML, team sync and SCIM provisioning depend on the edition you choose. Finally, plan the production foundation: a database other than SQLite for high availability, provisioned configuration under version control, and a tested recovery path. Each step should be recorded so that an auditor or your own security team can trace how the monitoring stack was set up and maintained.
Healthcare requirements that shape a Grafana build
This table maps each healthcare requirement that applies to a Grafana stack to its source and to the practical consequence for access, audit and hosting. Read it as a list of questions to settle with your compliance and legal teams before the build, not as a legal conclusion. The main takeaway is that monitoring data often reaches more people and systems than teams expect, so access and hosting decisions need to be made early.
| Requirement | What it asks for | What it means for the Grafana build |
|---|---|---|
| HIPAA Security Rule scope | Applies to covered entities and business associates for all ePHI they create, receive, maintain or transmit (45 CFR 164.302). | Confirm whether dashboards, logs, traces or alert payloads can contain ePHI. If they can, the monitoring stack is in scope even though it is not a clinical system. |
| Business associate terms | Contracts must require the business associate to meet the Security Rule, flow terms to subcontractors handling ePHI, and report security incidents (45 CFR 164.314). | If DeployOpen or another partner handles ePHI during implementation or support, the contract must reflect these terms. Ask who can see production telemetry and where support sessions are recorded. |
| Addressable specifications | For each addressable specification, assess whether it is reasonable and appropriate, document the decision, and implement an equivalent measure if not (45 CFR 164.306(d)). | Automatic logoff and encryption specifications are addressable. Record the chosen session timeouts, encryption in transit to data sources, and the reasoning behind each choice in the build record. |
| Unique user identification | Required. Each user of systems holding ePHI must have a unique identifier (Appendix A to Subpart C). | Shared Grafana accounts and shared dashboard logins fail this check. SAML, team sync and SCIM are Enterprise or Cloud features, so confirm which identity options your edition needs before design. |
| Proposed 2025 revision | HHS proposed a major Security Rule revision on 6 January 2025 (90 FR 898). No final rule had been published as of October 2026. | Do not treat the current rule as final. Design access, logging and encryption controls so they can be tightened, and ask your compliance lead to track the Unified Agenda entry for RIN 0945-AA22. |
| External access and MFA | A 3 September 2026 CNIL decision under GDPR Articles 32 and 34 cited external access to a patient record system without VPN or multi-factor authentication, and access control that ignored care team need to know. | Route remote access to Grafana through controlled network paths with multi-factor authentication. Scope dashboard permissions to the teams that need each clinical or operational view. |
| Audit evidence | The Security Rule expects documented policies and activity review. HHS does not certify compliance, and no private certification substitutes for it (HHS FAQ 2003). | Keep configuration as code through provisioning, retain access and login logs, and document who changed alert rules. Be wary of any vendor or consultant claiming a HIPAA certification. |
| NIS2 health sector | NIS2 Annex I lists health as a sector of high criticality, including healthcare providers and medical device manufacturers (Directive (EU) 2022/2555). | Where EU operations apply, confirm whether NIS2 obligations reach your organization and whether monitoring of clinical services must support incident reporting timelines. |
Which Grafana settings matter for clinical systems
The settings below decide whether a self-hosted Grafana instance can hold up under clinical monitoring: where its state lives, how it stays available, who can sign in, and what data reaches a dashboard. Each one is a decision a hospital IT or health software team should make and document before dashboards connect to EHR-adjacent systems.
Production database choice
Grafana keeps its configuration in SQLite by default, but the installation docs say SQLite does not scale for production. Plan on MySQL 8.0 or later or PostgreSQL 12 or later for any instance that serves clinical operations teams and any setup that needs high availability. Ask your DBA to confirm backup, encryption at rest and access controls for that database, since it holds dashboard definitions, data source credentials and user records.
Active-active high availability
Grafana high availability uses two or more active-active servers behind a load balancer, sharing one MySQL or PostgreSQL database with database-backed auth tokens. Alerting needs extra configuration to avoid duplicate notifications, and Grafana Live has limitations in this mode. Test failover with a clinical alert before go-live, and confirm that a duplicate page to on-call staff cannot happen during a node loss.
Enterprise identity and SAML
All editions support LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth. SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. Hospitals that need SAML with group-based access to clinical dashboards should price Enterprise into the design, or map roles through the identity provider's supported open-source options and document the gap for auditors.
Access control on sensitive dashboards
Restrict who can view dashboards that show patient-adjacent workflows, such as bed management, order queue latency or interface errors for a specific clinical unit. Confirm which folder and dashboard permissions the chosen edition enforces and which require Enterprise features. Review group membership quarterly, since unclear team mapping is a common route to over-broad access.
Provisioning as code
Provisioning loads data sources, dashboards, plugins and alerting resources from YAML or JSON files at startup. Grafana also documents Terraform and Git Sync. Keep these files in version control with change review, so every change to a clinical dashboard or alert rule has an approver and a history. Store data source credentials in secret references rather than in the files themselves.
Security hardening settings
The hardening guidance covers 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. Apply these at deployment and record each setting in the configuration baseline, because a hospital security review will ask for evidence of each one.
Data source choice sets what reaches dashboards
A dashboard can only show what its data source returns, so the data source decision is also a data protection decision. Logs from EHR interfaces, HL7 message brokers or application servers can carry identifiers in message bodies or labels. Choose sources that expose operational fields such as latency, error codes and throughput, and confirm with the data owner which fields are filtered or dropped before ingestion.
How to keep patient data out of dashboards, labels and alerts
The working rule is that monitoring data carries system identifiers, never patient identifiers. Metric labels, Loki stream labels, panel titles, annotations and alert payloads should name a service, host, interface, queue, ward system or integration engine, not a medical record number, name, date of birth, encounter ID or device serial tied to a person. Labels deserve the most attention because Grafana stores and indexes them, so a patient identifier placed in a label spreads into every query result, cache, backup and retention copy. Log lines are harder to control, since a parser that extracts a field from a message can expose whatever the application wrote there. Application teams in an EHR or clinical integration environment should agree this rule before instrumentation, and the OpenTelemetry Collector or log pipeline is the right place to drop or hash fields that slip through.
Query design and data source permissions enforce the rule in practice. Dashboards should aggregate by system dimensions, and any drill-down to individual records should happen in the source system under its own access controls, not through a Grafana panel that returns row-level clinical data. Data sources that reach clinical databases should use read-only accounts scoped to the monitoring views they need, and dashboards that must show sensitive detail belong in a restricted folder with explicit permissions. Review each dashboard, panel title, annotation text and the templates that render alert notifications for free-text fields, example log lines and variables populated from query results. Notification templates deserve particular scrutiny because a contact point such as email, chat or paging forwards that text outside the monitoring stack. Confirm the exact access model your edition supports, since fine-grained roles and team sync depend on the Grafana authentication and access control features you deploy.
This is a design decision for the privacy office and the clinical systems owner to confirm, not a setting a single toggle provides. Ask the privacy office which identifiers count as personal data in your jurisdiction and for which purposes monitoring may process any clinical context. Then record the labeling standard, the review steps for new dashboards and alert templates, and who approves exceptions. Test the rule with a sample of real queries and a deliberately injected test identifier to confirm it does not reach labels, panels or notifications. Repeat the review after each new integration, because a single new log format can introduce identifiers that the original design never considered.
How a healthcare Grafana rollout runs
The sequence moves from agreeing which systems and data classes are in scope to a handed-over, documented monitoring stack that the hospital runs itself. Each step closes with a decision or check that the privacy, security and clinical operations owners can sign off.
Scope systems and data classes with privacy and security
Before any build starts, the team lists the EHR, clinical, integration and supporting systems to be monitored, and classifies the data each one emits into logs, metrics, traces and labels. The privacy office and security office agree which fields may never reach Grafana, which teams may see which dashboards, and whether any HIPAA business associate terms apply to the vendors involved. Done means a signed scope document that names systems, data classes, excluded fields and owners.
Build the production database and HA layout
The team deploys Grafana on hospital-controlled infrastructure with MySQL 8.0 or later or PostgreSQL 12 or later as the configuration database, since SQLite is not suited to production or high availability. Two or more active-active Grafana servers sit behind a load balancer, and the team confirms how alerting will avoid duplicate notifications and which Grafana Live limitations apply. Done means a tested failover of one node and a documented restore path for the database.
Design identity and access
The team maps Grafana roles and folders to the care, operations and security teams that need them, and connects sign-in to the hospital's enterprise identity provider. Open-source and Enterprise editions differ on SAML, team sync, active sync and SCIM, so the team confirms which of these the hospital needs before choosing the edition. Done means a role matrix approved by the access owners and a test of sign-in, denial and removal for representative accounts.
Review data sources and dashboards for patient data
Each data source connection and dashboard query is reviewed for patient identifiers in panels, legends, variable values, annotations, log lines and metric labels. Queries are rewritten or filtered where needed, and sensitive dashboards are restricted to the teams listed in the scope document. Done means a review record for every connected source and dashboard, with a reviewer sign-off and any exceptions logged for the privacy office.
Route alerts to on-call teams
The team defines alert rules and notification routing so that clinical system alerts reach the right on-call rota, and alert messages carry system and severity details without patient data. Escalation paths and silences are tested with the operations team, including how alerts behave when one Grafana node is down. Done means a test alert delivered to each contact point and a documented escalation path reviewed by clinical operations.
Set up provisioning and change control
Data sources, dashboards and alerting resources are defined as files loaded at startup or managed through Git-based workflows, so changes are reviewed and reproducible. The team agrees on an approval path for dashboard and alert changes, a patch cadence that follows Grafana's published release guidance, and a test environment for upgrades. Done means a working provisioning repository, a documented change procedure and one successful dry-run upgrade.
Hand over runbooks and evidence
The team delivers architecture, access, data handling and recovery documentation, along with the evidence the hospital's compliance and audit functions asked for in scope. Operators are trained on routine tasks, backup restores and incident response for the monitoring stack itself. Done means a handover meeting with named owners, an accepted runbook set and a list of open items, including any HIPAA Security Rule controls that the hospital must still assess through its own compliance program.
HIPAA and adjacent frameworks for the monitoring stack
Grafana can hold evidence and enforce several controls that the HIPAA Security Rule expects, but no product makes a hospital or software provider compliant. The cards below separate the safeguards Grafana configuration can support, the contract and certification questions that sit outside it, and the adjacent frameworks that may apply to the same monitoring data.
Unique user identification in Grafana
The Security Rule's technical safeguards include unique user identification as a required specification. In Grafana, this means every engineer signs in with a named identity from your identity provider and no one shares the admin account or a generic viewer login. Check that the open-source edition's authentication options meet this need, because SAML, team sync and SCIM provisioning are documented only for Grafana Enterprise and Grafana Cloud. Confirm which identity provider path you will use before the design is fixed.
Emergency access and automatic logoff
Emergency access procedures are a required specification, and automatic logoff is addressable. For a monitoring console that displays clinical system health, define a break-glass path for administrators when the identity provider is unavailable, and record every use of it. Pair this with session timeouts set in your identity layer and a review of who can reach dashboards from shared workstations in clinical areas. Document the decision for each addressable specification, including the reason if you choose an equivalent measure.
Encryption as an addressable specification
Encryption of ePHI at rest and in transit appears in the technical safeguards as addressable, which means you must assess whether it is reasonable and appropriate and document the result. Grafana configuration databases, backups and the data sources feeding dashboards all need this assessment. Grafana's security hardening guidance covers secure and SameSite cookies and a Content Security Policy, so review those settings alongside your TLS termination and database encryption choices.
Business associate contracts for vendors
A business associate contract must require the vendor to follow the Security Rule, flow the same terms to subcontractors that handle ePHI, and report security incidents, including breaches of unsecured PHI. If a DeployOpen engagement or a managed Grafana host could access systems that contain ePHI, that contract question applies. Ask the implementation partner and any hosting provider whether they will sign a business associate agreement before access to the monitoring environment is granted.
No HIPAA certification, and OCR enforcement
HHS states that no Security Rule standard requires certification and that HHS does not endorse private certifications. Any vendor claiming a HIPAA certificate for a Grafana setup should be asked to explain the claim. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits, and penalties are inflation-adjusted, ranging from $145 per violation to $2,190,294 per violation with a calendar-year cap of $2,190,294. Those figures apply to penalties assessed on or after 28 January 2026.
Pending Security Rule revision
HHS proposed a major revision to the Security Rule on 6 January 2025, and as of October 2026 no final rule has been published. The Unified Agenda projects final action for July 2027. Treat the current requirements as the baseline, and track whether the final rule changes controls for monitoring, logging or encryption that your Grafana design already depends on. Plan a review point in your compliance calendar rather than assuming the proposal will be adopted unchanged.
Where HITRUST, NIS2 and GDPR fit
HITRUST is a voluntary assessment framework that some health organizations request from partners, with e1, i1 and r2 assessments on different cycles. NIS2 lists health as a sector of high criticality, and GDPR Articles 32 and 34 address security of processing and breach notification in the EU. A CNIL fine in September 2026 cited missing multi-factor authentication for external access to a patient record system, which is a monitoring-adjacent access control to review. Ask which of these apply to your organization before mapping controls.
On-premises, private cloud or Grafana Cloud for health data
A hospital data center keeps the monitoring stack on hardware and networks the hospital already controls. The hospital is the covered entity, so Security Rule duties for the stack sit with its own security and IT teams. An outside party changes that picture only when it administers the systems or can reach data inside them.
- Residency: Monitoring data stays in facilities the organization already audits, which simplifies answering where it lives and who can reach it.
- Business associate relationship: Staff-run hosting needs no new agreement for the hosting itself. An integrator that logs in, troubleshoots or administers the stack may need a business associate contract that meets 45 CFR 164.314.
- Database and high availability: Production needs MySQL 8.0 or later or PostgreSQL 12 or later, and high availability needs two or more active-active servers behind a load balancer.
- Cost drivers: Server capacity, database operations, on-call staffing and hardware refresh. These recur every year and grow with the number of users and data sources.
Confirm which staff and vendors can reach the stack, and whether backups and database replicas stay inside the same facilities.
A private cloud the organization controls moves the hardware into a cloud account, but the hospital still decides who administers it, which regions hold its data and how it is built. Residency becomes a question about the provider's regions, backup locations and support access. The hospital needs a contract that binds the provider when it stores or processes ePHI.
- Residency: Confirm the regions for compute, storage, backups, snapshots, logs and disaster recovery sites.
- Business associate relationship: A cloud provider that stores or processes ePHI usually needs a business associate agreement that passes the 45 CFR 164.314 terms down to its own subcontractors.
- Reproducible builds: Grafana supports provisioning files in YAML or JSON and documents further as-code options such as Terraform, which keep the stack rebuildable and its changes reviewable. See the Grafana provisioning docs.
- Cost drivers: Compute size, managed database, storage, cross-region traffic and the platform staff who run the environment. Most of these recur monthly.
Ask whether the provider will sign the agreement, which subprocessors it uses, and where its support staff can access the environment.
Grafana Cloud hosts the stack with Grafana Labs, so monitoring data, including any health information that reaches it, leaves the hospital's environment. The business associate question moves to Grafana Labs and its subprocessors. The hospital should not assume that a hosted service covers its HIPAA obligations without written terms.
- Business associate relationship: Obtain a business associate agreement from Grafana Labs in writing before any data reaches the service. The supplied information does not establish what Grafana Labs offers, so confirm it directly.
- Residency: Confirm the hosting region, backup locations and the countries where support staff can access data.
- Identity features: SAML, team sync, active sync and SCIM are available only in Grafana Enterprise and Grafana Cloud, which can shape the identity design. Review the Grafana pricing page for current tier terms.
- Cost drivers: According to the Grafana pricing page, the Pro tier starts with a 19 US dollar monthly platform fee plus usage, and the Enterprise tier has a minimum commitment of 25,000 US dollars per year. Usage charges recur and grow with data volume.
Request the agreement, the subprocessor list, region commitments, retention and deletion terms, and a quote that maps expected usage to data volume.
Questions hospital and health software teams ask before hiring help
What drives the cost of a healthcare Grafana implementation?
The main drivers are how many data sources you connect, how many systems fall under clinical or patient-facing scope, how many environments you need (production, test and disaster recovery), and how much evidence your compliance team expects from the monitoring stack. Each of these changes the number of connectors to build, the access model to design and the testing to run. Work is usually split between one-time items such as design, build, hardening and documentation, and recurring items such as upgrades, patching and support. Ask for a written scope that lists each data source, each environment, each identity integration and each deliverable so the quote can be compared line by line.
How long does it take to get a healthcare Grafana stack into production?
The timeline depends on the scope in the written agreement, not on a standard number. Grafana's own guidance states that small deployments under 25 concurrent users need 2 cores and 2 to 4 GB of RAM, but a hospital rollout usually adds network approvals, identity integration, database design and change control on top of that. Expect the largest delays to come from approvals, not from installation. Ask the partner to show which steps depend on your teams, such as firewall requests, directory group creation and clinical informatics sign-off, and build those dates into the plan.
What does the hospital need to provide for the project?
Plan for input from four groups. Privacy and compliance staff need to confirm which fields may appear in dashboards, labels and logs. Security staff need to approve identity, network paths, secrets handling and access roles. Clinical informatics staff need to explain how EHR and clinical systems are used so dashboards show the right operational signals. Network teams need to provide hosting, segmentation and routing to the data sources. Name one decision-maker per group before work starts, because open questions about patient identifiers and access rules usually cause the most rework.
Can our internal team build and run Grafana without a partner?
Often yes, if you have engineers who already run Linux, containers or Kubernetes, a database team that can support MySQL or PostgreSQL, and staff who know your clinical systems. Grafana documents packages for Debian and Ubuntu, RHEL and Fedora, SUSE, Docker images and Helm charts, so the installation itself is not the hard part. The harder work is the design around patient data, the high availability setup and the ongoing upgrades. Grafana's upgrade guidance says minor releases arrive every other month and patch releases at least monthly, so decide who owns that cycle before you commit. A partner is most useful for fixed-scope design, hardening and handover.
Do we need Grafana Enterprise for SAML and SCIM?
Yes, if you need SAML, team sync, active sync or SCIM provisioning on self-hosted Grafana. Grafana's authentication documentation says LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT work in all editions, while SAML, team sync, active sync and SCIM provisioning are limited to Grafana Enterprise and Grafana Cloud. Many hospitals already use one of the supported OAuth or LDAP options, so confirm your identity provider and required features before buying a license. Enterprise is a commercial product with its own terms, so ask for a written quote and licensing terms as part of the scope.
What does HIPAA require for a monitoring stack, and what does it not require?
HIPAA's Security Rule applies to covered entities and business associates for electronic protected health information they create, receive, maintain or transmit. A monitoring stack that touches ePHI, even through labels or logs, falls within that scope, so the rule's safeguards should be mapped to it. HIPAA does not issue a certificate. HHS states that no Security Rule standard requires certification and that private certifications do not stop HHS from finding a violation. Independent auditors do not certify HIPAA either in the sense of a federal seal. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports or attestations. Ask counsel to confirm the scope of your covered and business associate relationships.
How is a quote produced for a healthcare Grafana project?
A quote follows from written scope. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list. For a healthcare project, the scope should list the data sources, environments, identity method, hosting model, dashboard and alerting requirements, the privacy review of labels and log fields, and the documentation and handover items. Ongoing support, upgrades and continuous testing are available as retainers, so ask for one-time and recurring costs as separate lines. Ask for the assumptions behind each line and what changes the price if an assumption fails.
What should a healthcare team confirm before choosing on-premises Grafana hosting?
Confirm where the data sources and Grafana servers will run, who can reach them and how backups are stored. Grafana stores configuration in SQLite by default, but its installation documentation says SQLite does not scale for production, so MySQL 8.0 or later or PostgreSQL 12 or later is required for production and high availability. High availability uses two or more active-active servers behind a load balancer, and the documentation notes that alerting needs extra configuration to avoid duplicate notifications. Confirm these items with your database and network teams, and check the official installation and high availability pages before you finalize the design.
What to ask a partner before signing a healthcare scope
Start with ePHI exposure, because a monitoring stack can leak patient data without anyone intending it. Ask the partner how they will keep identifiers out of dashboard titles, panel queries, annotations, alert templates, log labels and exported snapshots, and who reviews those choices. Ask for the query and label naming rules they will apply to your data sources, and whether they will test a sample of dashboards against a written list of prohibited fields before go-live. A credible answer names specific places where data gets copied: Loki stream labels, Prometheus label cardinality, alert notification payloads and the Grafana database itself. Ask them to confirm what they will not connect to Grafana at all.
Next, establish whether the partner will sign a business associate contract before they touch any system that holds ePHI. Under 45 CFR 164.314(a)(2)(i), that contract must require Security Rule compliance, flow the same terms to subcontractors and require incident reporting to you. Ask who in their organization owns that obligation, which subcontractors (hosting, monitoring or support) could see ePHI, and how a security incident would reach your team. Also ask how they will handle access and audit records: which named roles can administer Grafana, whether SSO through SAML or Entra ID is planned, whether team sync is needed, and how administrative actions are logged. Confirm with the partner whether these features depend on Grafana Enterprise, since the authentication docs limit SAML and team sync to that edition and Grafana Cloud.
Finally, ask for the upgrade method and the evidence package. Grafana's upgrade guidance describes annual major releases, bimonthly minor releases, monthly patches and support windows of 9 months per minor release and 15 months for the last minor of a major version, so ask how the partner will keep you on a supported line and who approves each patch in a regulated change process. Request sample artifacts before signing: a hardening baseline, provisioning files kept in version control, backup and restore test records, and an access review. Be clear that none of this makes the stack HIPAA certified. HHS states there is no HIPAA certification, so ask the partner to show what they prepare for your risk analysis instead.
How DeployOpen scopes and delivers healthcare Grafana work
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so healthcare monitoring data stays where your governance says it should. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Map which EHR, clinical and supporting systems are monitored, and which metrics, logs and traces each one produces.
- Record where Grafana will run, which data sources it may query, and which network zones it may reach.
- Agree in writing which dashboards, labels and alert payloads must exclude patient identifiers and who may view them.
How we build
- Deploy Grafana on infrastructure you control with a production database, TLS, and access restricted to approved identity sources.
- Configure data sources, dashboards and alert rules as provisioned files so changes are reviewed, versioned and repeatable.
- Test label hygiene, role separation and alert routing against sample data before any clinical system is connected.
How we hand over
- Deliver configuration, provisioning files, runbooks and a record of the access and data decisions made during scoping.
- Walk your operations, security and clinical IT staff through alert routing, user administration and restore steps.
- Document the controls the stack supports and the evidence it produces, and state which items remain with your organization or an assessor.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, if your team wants it.
- Plan upgrades against Grafana's published release cadence and support windows, with changes tested in a non-production instance first.
- Re-review dashboards and data source access when new clinical systems or staff roles are added to the monitoring scope.
