> ## Documentation Index
> Fetch the complete documentation index at: https://support.configview.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Grafana Cloud setup

ConfigView reads Grafana Cloud through **two separate APIs that use two separate credentials**, so Grafana Cloud appears in ConfigView as two integrations that share this page:

| Integration | Reads | Credential |
| - | - | - |
| **Grafana Cloud** (`grafana`) | Your Grafana Cloud organization on grafana.com: stacks, organization members, access policies and the metadata of their tokens | A Cloud Access Policy token and your organization slug |
| **Grafana Cloud - Stack** (`grafana-stack`) | One stack's own Grafana: users and roles, teams, service accounts and their tokens, data sources, single sign-on providers | A service account token and the stack URL |

You can set up either one or both. They do not depend on each other. The stack integration also works for self-hosted Grafana.

> **A Cloud Access Policy token cannot read a stack, and a stack service account token cannot read grafana.com.** That is Grafana's design, not a ConfigView limit. It is why there are two sets of secrets.

ConfigView only reads. It never creates, changes or deletes anything in Grafana, and it never stores token values, client secrets or data source passwords.

***

## Part 1: Grafana Cloud (organization)

You will end up with **2 required secrets** (`GRAFANA_CLOUD_TOKEN`, `GRAFANA_ORG_SLUG`).

### What you need

* Grafana Cloud organization admin rights (to create an access policy)

### Step 1: Open the Grafana Cloud page in ConfigView

Open ConfigView in a second browser tab and leave it open:

`https://{companyname}.configview.com/admin/integrations/grafana`

### Step 2: Create a read-only access policy and token

1. Sign in to Grafana Cloud and open **Administration → Users and access → Cloud access policies** (in the Cloud Portal: **Security → Access Policies**)
2. Click **Create access policy**. Name it `ConfigView`
3. Set the **realm** to your **whole organization**
4. Tick only these scopes:

| Scope | Used for |
| - | - |
| `orgs:read` | The organization |
| `stacks:read` | Your stacks and the regions they run in |
| `accesspolicies:read` | Access policies and their tokens |
| `org-members:read` | The people in the organization and their roles |

Don't tick any `:write` or `:delete` scope. ConfigView never uses them.

5. Click **Create**, then **Add token** on the new policy. Give it an expiry date you will remember to renew, and copy the token (it starts `glc_` and is shown once)
6. In the ConfigView tab, paste it into `GRAFANA_CLOUD_TOKEN` and save
7. Enter your organization slug in `GRAFANA_ORG_SLUG`. It is the last part of `https://grafana.com/orgs/<slug>`: not the display name and not a stack name

### Step 3: Connect and verify

Click **Connect**, then **Verify now**. The health check reads both secrets, reads the organization, lists your stacks, then tries one access policy, one token and the member list.

| Script | Notes |
| - | - |
| **Stacks** | Name, URL, region, plan, status, version, creator and active users per stack. |
| **Access Policies** | Scopes each policy grants, flagging write scopes and the ones that can change access, the realm and any IP restriction. Read in each region where you run a stack. |
| **Access Policy Tokens** | Token name, its policy, expiry or none, first and last use. Values are never stored. |
| **Organization Members** | grafana.com organization members and their role (Admin, Editor, Viewer, Billing Admin). |

If a check fails:

* **401.** The token is wrong, expired or deleted. Create a new one.
* **403 on a step.** The access policy lacks that scope (see the table).
* **404 on the organization.** `GRAFANA_ORG_SLUG` is wrong, or the policy belongs to a different organization.
* **Organization Members shows as skipped.** The `org-members:read` scope is missing. This area is optional.
* **Access policies says no regions are known.** The organization has no stacks, so there is nothing to read.

***

## Part 2: Grafana Cloud - Stack

You will end up with **2 required secrets** (`GRAFANA_STACK_URL`, `GRAFANA_STACK_TOKEN`). One integration reads one stack; add a second Grafana Cloud - Stack instance for another stack.

### What you need

* Admin rights in the stack (to create a service account)

### Step 1: Open the page in ConfigView

`https://{companyname}.configview.com/admin/integrations/grafana-stack`

### Step 2: Create a service account and token

1. In your stack, open **Administration → Users and access → Service accounts** and click **Add service account**. Name it `ConfigView`
2. Choose the role. **Viewer is not enough**: in Grafana, the Viewer and Editor roles cannot list users, teams, service accounts or data sources. Choose **Admin**.
   * If you are on Grafana Cloud Pro or Enterprise you can instead give the service account a **custom role** that holds only read permissions: `org.users:read`, `teams:read`, `teams.permissions:read`, `serviceaccounts:read` and `datasources:read` (plus `settings:read` for SSO providers). That is the safest option because the token cannot change anything.
3. On the service account, click **Add service account token**. Set an expiry and copy the token (it starts `glsa_` and is shown once)
4. In ConfigView, paste it into `GRAFANA_STACK_TOKEN`
5. Enter the stack address in `GRAFANA_STACK_URL`, for example `https://acme.grafana.net`. You find it in the Cloud Portal under your stack's **Details**

> An Admin service account token can change Grafana. Store it only in ConfigView, give it an expiry, and use the custom role above where your plan allows.

### Step 3: Connect and verify

Click **Connect**, then **Verify now**. The health check reads both secrets, calls the stack, then tries each area. Areas the token cannot read are shown as skipped, and if the token reaches nothing it says so.

| Script | Notes |
| - | - |
| **Users** | Every user in the stack's organization with role, last seen and disabled state. |
| **Teams** and **Team Members** | Teams and who is in them. One request per team. |
| **Service Accounts** | Service accounts with role, disabled state and token count. |
| **Service Account Tokens** | Token metadata per service account: created, expiry (none = never expires), expired. One request per service account. |
| **Data Sources** | Each data source's type and the host it points at. |
| **SSO Providers** | Sign-in providers (GitHub, Google, Azure AD, Okta, SAML...) and their settings. Needs `settings:read`, which on most stacks only a Grafana server admin has, so this is often skipped. |

If a check fails:

* **401.** The token is wrong, expired or disabled, or it is a `glc_` Cloud Access Policy token. A stack needs a `glsa_` service account token.
* **Everything but the stack check is skipped.** The service account is a Viewer. Give it the Admin role or the custom role above.

***

## Data Tables

Each table has a `run_at` column and a `raw_json` column holding the record as Grafana returned it, minus anything listed under *What isn't collected*. Each table keeps only the newest run.

| Table | Source | Key Columns |
| - | - | - |
| `grafana_stacks` | `GET /api/orgs/{org}/instances` | slug, stack\_url, region\_slug, plan\_name, stack\_status, current\_active\_users, created\_at |
| `grafana_access_policies` | `GET /api/v1/accesspolicies?region=` | policy\_id, region, scopes, has\_write\_scopes, can\_manage\_org, realms, allowed\_subnets |
| `grafana_access_policy_tokens` | `GET /api/v1/tokens?region=` | token\_id, policy\_name, expires\_at, never\_expires, first\_used\_at, last\_used\_at |
| `grafana_org_members` | `GET /api/orgs/{org}/members` | email, login, org\_role |
| `grafana_users` | `GET /api/org/users` | email, login, org\_role, last\_seen\_at, is\_disabled |
| `grafana_teams` | `GET /api/teams/search` | team\_id, name, email, member\_count |
| `grafana_team_members` | `GET /api/teams/{id}/members` | team\_id, email, login, is\_team\_admin |
| `grafana_service_accounts` | `GET /api/serviceaccounts/search` | service\_account\_id, name, org\_role, is\_disabled, token\_count |
| `grafana_service_account_tokens` | `GET /api/serviceaccounts/{id}/tokens` | token\_name, service\_account\_name, expires\_at, never\_expires, has\_expired, last\_used\_at |
| `grafana_datasources` | `GET /api/datasources` | name, datasource\_type, target\_host, target\_scheme, uses\_basic\_auth |
| `grafana_sso_providers` | `GET /api/v1/sso-settings` | provider, is\_enabled, allow\_sign\_up, allowed\_domains, auto\_login |

***

## Things worth knowing

**Access policies are read per region.** Grafana lists them one region at a time, so ConfigView reads the regions where your organization has a stack. A policy created in a region with no stack is not seen.

**Write scopes are not all alike.** `metrics:write` or `logs:write` only lets a token send data. ConfigView separates those from scopes on `accesspolicies`, `stacks`, `orgs`, `org-members` and `stack-service-accounts`, which let a token create more access (`can_manage_org`).

**"Never expires" is a finding.** A token with no expiry works until someone deletes it. Both token tables mark them, and the catalog lists them.

**Last-used dates.** Cloud Access Policy tokens report first and last use. Service account tokens report creation and expiry; ConfigView also stores a last-used date if your Grafana version returns one.

**Single stack, single organization.** A service account token belongs to one organization of one stack, so the stack integration lists that organization's users.

**Rate limits.** Grafana documents 600 requests per hour for the access policy endpoints; the collectors stay under it. It publishes no limit for the other endpoints. Collectors pace themselves and wait if Grafana answers 429.

## What isn't collected

* Access policy token values, service account token values and legacy API key values
* Data source passwords, basic auth users, `secureJsonData`, `jsonData` and the full data source URL (only its scheme and host are kept)
* SSO client secrets, private keys, certificates and signing keys
* Dashboards, folders, alert rules, query data and any metrics, logs or traces
* Billing, invoices and payment details


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.