🚨 Grafana Error Guide: 'Datasource type not exist' — Fix Provisioning and Plugin Datasources

Overview

Grafana raises this at startup or provisioning reload when a datasources.yaml file (or an API call) declares a datasource whose type isn’t a registered plugin. The provisioning step fails and the log reads:

Datasource provisioning error: datasource.type "grafana-x-datasource" does not exist

A closely related variant appears when the plugin exists but wasn’t loaded:

Registering plugin failed: plugin "grafana-x-datasource" is not signed

Both mean the same practical thing: Grafana can’t map the type string in your provisioning to an installed, loaded datasource plugin — so the datasource is never created and dashboards that reference it show “Datasource not found”.

Symptoms

• Grafana logs datasource.type "..." does not exist at boot; the datasource never appears under Connections.
• Dashboards referencing that datasource UID show Datasource <uid> was not found.
• The problem started after a version upgrade, a plugin removal, or copying provisioning between instances.
• Built-in types (prometheus, loki) work; only a plugin-based type (Zabbix, Infinity, a cloud plugin) fails.
• grafana-cli plugins ls doesn’t list the expected plugin, or it’s present but unsigned/blocked.

Common Root Causes

• Missing plugin — the datasource is a plugin (not a core type) that was never installed, or was dropped on upgrade.
• Typo or wrong type string in datasources.yaml (e.g. postgres vs grafana-postgresql-datasource, or a renamed plugin ID).
• Unsigned/blocked plugin not in allow_loading_unsigned_plugins, so it fails to register even though its files exist.
• Plugin installed in the wrong path — a custom GF_PATHS_PLUGINS that Grafana isn’t reading.
• Version incompatibility — the plugin doesn’t support the running Grafana version and won’t load.
• Air-gapped install where the plugin couldn’t be fetched at build time.

Diagnostic Workflow

1. Read the exact type string Grafana rejected. The log quotes it verbatim:

journalctl -u grafana-server --since '10 min ago' | grep -i 'does not exist\|plugin'

2. List installed plugins and compare the type. Confirm whether the plugin is present and loaded:

grafana-cli plugins ls
# In a container
docker exec grafana grafana-cli plugins ls

If the type in your YAML isn’t in this list, it’s not installed (or not loaded).

3. Verify the correct plugin ID / type. Datasource type must equal the plugin ID, not a friendly name:

# Search the catalog for the real plugin id
grafana-cli plugins list-remote | grep -i infinity

For example, the JSON/API datasource is yesoreyeram-infinity-datasource, PostgreSQL is grafana-postgresql-datasource.

4. Install the missing plugin and restart.

grafana-cli plugins install yesoreyeram-infinity-datasource
sudo systemctl restart grafana-server

5. If it’s unsigned, allow it explicitly in grafana.ini (only for trusted plugins):

[plugins]
allow_loading_unsigned_plugins = yesoreyeram-infinity-datasource

6. Confirm the provisioning type matches. Corrected datasources.yaml:

apiVersion: 1
datasources:
  - name: JSON API
    type: yesoreyeram-infinity-datasource
    uid: infinity-prod
    access: proxy
    url: https://api.example.com

Reload provisioning (restart, or POST /api/admin/provisioning/datasources/reload) and check the log is clean.

Example Root Cause Analysis

A platform team promoted their Grafana provisioning repo to a new cluster built from a slim custom image. Boot logs showed datasource.type "yesoreyeram-infinity-datasource" does not exist, and every Infinity-backed dashboard reported “Datasource not found.” The identical provisioning had worked on the old instance.

grafana-cli plugins ls on the new pod listed only core plugins — the Infinity datasource wasn’t installed. The old image had baked the plugin in during its build; the new slim image’s Dockerfile omitted the grafana-cli plugins install step, so the type string had nothing to bind to.

Fix: added grafana-cli plugins install yesoreyeram-infinity-datasource to the image build (and pinned its version), rebuilt, and redeployed. Provisioning applied cleanly and the datasource appeared. The provisioning YAML was correct all along — the plugin behind its type was simply absent.

Prevention Best Practices

• Bake required plugins into the image (or set GF_INSTALL_PLUGINS) so provisioning types always have a backing plugin.
• Pin plugin versions alongside the Grafana version to avoid load failures after upgrades.
• Use the exact plugin ID as type in provisioning; keep a documented map of friendly name → plugin ID.
• Validate provisioning in CI by booting Grafana against the config and failing on does not exist log lines.
• Scope allow_loading_unsigned_plugins narrowly to specific trusted IDs, never blanket-allow.
• Keep provisioning and installed plugins in the same source of truth so promoting config between environments carries its dependencies.

Quick Command Reference

# See the rejected type
journalctl -u grafana-server --since '10 min ago' | grep -i 'does not exist'

# List installed plugins
grafana-cli plugins ls

# Find the correct plugin id
grafana-cli plugins list-remote | grep -i <name>

# Install and restart
grafana-cli plugins install <plugin-id> && sudo systemctl restart grafana-server

# Reload provisioning without full restart
curl -s -X POST -H "Authorization: Bearer $GRAFANA_TOKEN" \
  http://localhost:3000/api/admin/provisioning/datasources/reload

Conclusion

datasource type does not exist means Grafana has no installed plugin matching the type in your provisioning — usually a missing plugin, a wrong plugin ID, or an unsigned plugin that failed to load. Read the exact type from the log, compare it to grafana-cli plugins ls, install (and pin) the right plugin ID, and reload. Bake plugin dependencies into your image so provisioning promoted between environments never arrives without the plugins it needs.