Fix Grafana "Datasource Not Found" After Provisioning (2026)

Grafana’s "Datasource Not Found" error after provisioning means the Grafana backend can’t reach or authenticate with the data source you’ve configured.

Common Causes and Fixes:

1. Network Connectivity Issues:

• Diagnosis: From the Grafana server, try to curl the data source’s API endpoint.

  curl -v <datasource_url>
  

  For example, if your data source URL is http://prometheus:9090, you’d run curl -v http://prometheus:9090. Look for "Connection refused," "timed out," or DNS resolution errors.
• Fix: Ensure the Grafana server can resolve and reach the data source’s hostname and port. This might involve:
  • Updating /etc/hosts on the Grafana server:

    192.168.1.100  prometheus.internal
    

    This directly maps the hostname to an IP, bypassing DNS.
  • Adjusting firewall rules (e.g., ufw or iptables) on the Grafana server or the data source server to allow traffic on the specific port (e.g., 9090 for Prometheus, 8086 for InfluxDB).

    # Example for ufw
    sudo ufw allow from <grafana_server_ip> to any port 9090
    

    This opens the port on the data source server to accept connections from the Grafana server.
  • Verifying Docker network configurations if Grafana and the data source are in separate Docker networks or containers. Ensure they are on the same network or have appropriate inter-network routing.
• Why it works: This establishes the fundamental ability for Grafana to communicate over the network to the data source’s API.

2. Incorrect Data Source URL or Port:

• Diagnosis: Double-check the url field in your Grafana provisioning file (e.g., /etc/grafana/provisioning/datasources/my-datasource.yml).

  apiVersion: 1
  datasources:
    - name: Prometheus
      type: prometheus
      access: proxy
      url: http://prometheus:9090  # <-- Verify this exact string
      isDefault: true
      editable: false
  

  Ensure there are no typos, missing ports (like :9090), or incorrect protocols (http vs. https).
• Fix: Correct the url field in the YAML file to match the actual, resolvable endpoint of your data source. For instance, if your Prometheus is running on 192.168.1.50 on port 9090, the URL should be http://192.168.1.50:9090.
• Why it works: Grafana uses this URL to construct its HTTP requests to the data source. An incorrect URL means it’s trying to talk to the wrong place.

3. TLS/SSL Certificate Issues (for https datasources):

• Diagnosis: If your data source uses HTTPS, check the Grafana server logs (/var/log/grafana/grafana.log or via journalctl -u grafana-server) for TLS handshake errors, certificate validation failures, or "remote error: tls: bad certificate."
• Fix:
  • If using self-signed certificates: You need to tell Grafana to trust the data source’s certificate. In the datasource provisioning file, add:

    # ... other fields ...
    secureJsonData:
      tlsSkipVerify: true # <-- Set this to true if you want to skip verification
    # Or, to provide a custom CA certificate:
    # tlsCaCert: |
    #   -----BEGIN CERTIFICATE-----
    #   ... your CA cert content ...
    #   -----END CERTIFICATE-----
    

    Restart Grafana for the change to take effect.
  • If using certificates signed by a known CA: Ensure the Grafana server trusts the CA that signed the data source’s certificate. This usually means the CA’s root certificate is present in the system’s trust store (/etc/ssl/certs/ on many Linux systems). If not, you might need to add it and update the certificate store.
• Why it works: This ensures Grafana’s HTTP client can successfully establish a secure, encrypted connection with the data source’s HTTPS endpoint.

4. Authentication/Authorization Failures:

• Diagnosis: Check Grafana logs for messages like "unauthorized," "forbidden," "401 Unauthorized," or "403 Forbidden" when trying to query the data source. Also, check the data source’s own logs for incoming connection attempts and their status.
• Fix:
  • API Keys/Tokens: If your data source requires an API key or token, ensure it’s correctly entered in the secureJsonData section of the provisioning file.

    # ... other fields ...
    secureJsonData:
      basicAuthPassword: "your_api_key_or_token" # Or specific field like apiKey: "..."
    

    Also, verify the API key is still valid and has the necessary permissions within the data source.
  • Basic Authentication: If using basic auth, ensure the username and password are correct and properly formatted in secureJsonData.

    # ... other fields ...
    secureJsonData:
      basicAuthPassword: "your_password"
    basicAuthUser: "your_username"
    

  • Permissions: On the data source side, confirm the user or service account associated with the credentials has read access to the data you’re trying to query.
• Why it works: This grants Grafana the necessary credentials to authenticate with the data source’s API, proving its identity.

5. Data Source Service Not Running or Healthy:

• Diagnosis: Verify the data source service itself is running.

  # For systemd services
  systemctl status <datasource_service_name>
  # For Docker containers
  docker ps | grep <datasource_container_name>
  

  Check the data source’s own logs for any errors or startup failures.
• Fix: Start or restart the data source service.

  # For systemd services
  systemctl start <datasource_service_name>
  # For Docker containers
  docker start <datasource_container_name>
  

  Address any errors reported in the data source’s logs.
• Why it works: Grafana can’t connect to a data source that isn’t running or is in a failed state.

6. Proxy Configuration (Grafana Side):

• Diagnosis: If Grafana is behind a reverse proxy (like Nginx or Traefik), check the proxy’s logs for any connection errors or misconfigurations related to Grafana’s outgoing requests. Also, check Grafana’s own configuration (grafana.ini) for [http_proxy] settings.
• Fix: Ensure the reverse proxy is configured to allow outgoing connections to your data source’s IP/port. If Grafana itself needs to use a proxy to reach the data source, configure the http_proxy and https_proxy settings in grafana.ini (or via environment variables).

  [http_proxy]
  enabled = true
  url = http://your-proxy.example.com:8080
  # no_proxy = localhost,127.0.0.1,grafana.local,prometheus.internal
  

• Why it works: This ensures that Grafana’s network requests can successfully traverse any intermediate proxy infrastructure.

7. Incorrect Data Source Type:

• Diagnosis: Review the type field in your datasource provisioning file.

  # ...
  type: prometheus # <-- Ensure this matches your actual data source
  # ...
  

  Common mistakes include typos (e.g., promethues) or using the wrong type identifier for the data source.
• Fix: Correct the type field to the exact identifier Grafana expects for your data source. You can find these in Grafana’s UI (when adding a data source manually) or in its documentation. For example, Prometheus is prometheus, InfluxDB is influxdb, Elasticsearch is elasticsearch.
• Why it works: Grafana uses the type field to load the correct plugin and know how to interact with the data source’s API. An incorrect type means Grafana doesn’t know how to communicate.

The next error you might encounter is "Internal Server Error" if the data source is now reachable but returns malformed data or if there’s a configuration issue within the data source itself that prevents it from serving valid query results.