Grafana Infinity data source for REST APIs, JSON and CSV: what it does and when to use it
Use the Infinity plugin when an internal system already exposes its data over HTTP or in files, but Grafana has no dedicated data source for it. Typical examples are a ticketing API that returns JSON, a batch job that writes a CSV report to a file share, or an older service that answers in XML. Infinity is a plugin, not part of core Grafana: you add it from the plugin catalog to your self-hosted instance, and it then queries REST, JSON, CSV and XML endpoints and turns the responses into panels and tables. Before you build anything, confirm the plugin version your Grafana release supports and check that your security team accepts an external plugin in the environment.
Infinity is confirmed to work with externally shared dashboards, as listed in the Grafana shared dashboards documentation. That matters if a dashboard built on a REST endpoint must be shown outside your network, but it does not remove the need to review what the endpoint returns to anonymous viewers. Ask who will own each query, which credentials it uses, and whether the source system is allowed to serve data to a Grafana server at all. Confirm these points with the owner of each internal system before you commit to Infinity as the route.
Choose Infinity for read-only, moderate-volume views where the source is stable and already available over HTTP or files. Consider a small custom data source plugin instead when the source needs complex pagination or session logic, when queries must be built through a guided editor, or when the same integration will serve many teams and needs versioned code review. A custom plugin carries its own build, signing and upgrade work, so its cost recurs with every Grafana release. For alerting on the same data, plan a backend that parses and evaluates the response rather than relying on panel queries alone, which the next section covers.
What you need before installing Infinity on self-hosted Grafana
Infinity runs inside your Grafana server, so the work starts with the platform underneath it. The cards below cover the instance and database, who can install plugins, the network paths to each endpoint, certificate trust and ownership of every API. Settle these before building any dashboard, because each one decides whether queries work, and whether they keep working.
Grafana instance and production database
Infinity requests are made by the Grafana server, not by the browser, so the server is the place where every endpoint has to be reachable. Confirm you are running a current Grafana release on a production database. SQLite is fine for a trial, but Grafana's installation docs say it does not scale for production, so plan for MySQL or PostgreSQL before you add shared dashboards that depend on Infinity. Confirm the Infinity plugin version against your Grafana release using the plugin catalog and its release notes, since plugin and core versions move on their own schedules.
Plugin installation rights
Infinity is a plugin, so someone must be allowed to install it and, in a restricted environment, to supply its package. Decide who holds that right: a platform team through configuration management, or a Grafana administrator through the UI. Check whether your change process requires a ticket or review for plugin installs, and whether the Grafana server can reach the plugin catalog or needs an offline copy. Record the installed version so a later upgrade does not silently change query behavior.
Outbound network paths to each endpoint
Every REST, JSON, CSV or XML source needs a network path from the Grafana server, including DNS resolution, firewall rules and any proxy. A path that works from a laptop often fails from the server, and a dashboard panel then shows an error that looks like a query problem. List each host, port and protocol, and confirm that the Grafana server, not your workstation, can reach it. Also decide whether the endpoints should be allowed only from the Grafana network segment.
TLS trust for internal certificates
Internal APIs often use certificates issued by a private certificate authority. The Grafana server must trust that chain at the operating system or container level, or Infinity requests fail during the TLS handshake. Ask the API owner which CA signed the certificate, whether the chain includes intermediates, and how renewals are published. Plan a renewal date for each certificate so a rotated certificate does not break panels and alert rules that depend on the same endpoint.
Credentials and secret storage
Most internal APIs require a token, key or service account. Decide where the secret lives, who can read it and how it rotates before you configure a data source. Infinity data source settings are visible to users with the right permissions, so a credential pasted into a dashboard or shared alongside it becomes widely available. Ask each API owner for a dedicated, read-only identity for Grafana, so revoking it does not affect other integrations.
A named owner for each API
Each endpoint needs one accountable owner who can answer questions about its schema, its rate limits, its maintenance windows and its change history. Without that owner, a renamed JSON field or a changed CSV column breaks a dashboard and nobody knows whom to ask. Record the owner, the escalation contact and the expected change notice for every source. The owner should also confirm whether the endpoint is intended for machine polling, since frequent queries from dashboards and alert rules add load to systems that were not built for it.
How to configure Infinity against a REST or file source
This sequence takes a team from installing the Infinity plugin to a single panel that returns the rows they expect from a REST endpoint or file. Each step ends with a check so problems surface before dashboards depend on the query.
Confirm the plugin source and install Infinity
A Grafana administrator on the self-hosted instance installs the Infinity data source plugin from the plugin catalog or through the plugin installation method the team already uses for its Grafana packages, such as a container image build or a configuration file that lists plugins. Before installing, the team should confirm the plugin version against the Grafana version it runs, using the plugin's listing in the catalog, and record who approved the plugin in change control. The step is done when Infinity appears in the list of installed data sources and the Grafana server log shows the plugin loaded without signature or startup errors. If the instance restricts outbound traffic, the admin should also confirm that the plugin can be fetched from the catalog or that an approved copy is available internally.
Create the Infinity data source
An administrator adds an Infinity data source under Connections, or defines it in a provisioning file so the configuration can be reviewed and promoted between environments. The data source is the place to set shared defaults such as allowed hosts, headers that every request needs, and TLS settings for internal certificates. Keep credentials out of dashboard JSON and put them in the data source secure fields or in the secrets store the team uses. The step is complete when the data source saves and its built-in test succeeds against a simple, documented endpoint that the team controls, which confirms network reachability and TLS trust before any query logic is involved.
Set the base URL and authentication
The team sets the base URL for the API or the location of the file, then chooses an authentication method that matches the source, such as an API key header, a bearer token or basic credentials, depending on what the endpoint documents. Use a read-only service account where the API supports one, and confirm with the source owner which scopes or roles the account needs. Authentication values belong in secure fields, not in query text. The check for this step is a manual request from the Grafana host, or the test result from the data source page, returning a successful status code and the expected payload without exposing the secret in logs or the browser.
Define the request and choose the parser
In a test panel, the builder defines the request method, path, query parameters and any body, then selects the parser for the response format: JSON, CSV or XML. For JSON, the team identifies the root path that holds the records so the parser can reach an array of objects. For CSV, it confirms the delimiter, whether the first row holds headers and how the file encoding is set. For XML, it confirms the element that repeats per record. Choose a parser by checking the raw response first, since a mismatch between declared content type and actual payload is a common cause of empty panels. The check is a preview of the parsed output showing the column names and a sample of rows that match the source.
Map fields to columns and types
The team maps source fields to the columns a panel needs, setting a timestamp column for time series, a numeric column for values and labels for grouping. Infinity can apply column types so text that looks numeric is treated as a number and date strings are read as times. The mapping should use the most specific path the payload supports, and any filtering or aggregation that can be done at the source should be done there to limit the amount of data fetched on each refresh. The check is that the columns appear with the expected types in the query preview, and that a sample timestamp converts to the correct time zone and date.
Test with one panel before building dashboards
Before anything is copied into a dashboard, one time series or table panel is built against the mapped query and run with a short time range. The team compares the panel output row by row with the source for a known record, checks the count of rows, and confirms that a changed value in the source appears after the refresh interval. It also checks the behavior when the endpoint returns an error or an empty set, because panels that silently show nothing will mislead operators. The step is complete when a named reviewer on the team signs off that the panel matches the source for the agreed sample.
Decide how the query moves into shared dashboards and alerts
Once the single panel is verified, the team decides how it will be reused. Dashboards that other teams open should reference the data source by a stable name and avoid embedding credentials. For alert rules, confirm that the query returns the shape the alerting engine expects, and test the rule against a known condition before enabling notifications. The team should also confirm that the Infinity data source is supported on any externally shared dashboards it plans to publish by checking the Grafana documentation for shared dashboards, and should review whether the query volume or the source's rate limits make a small custom data source plugin the better fit. The check is a documented data source name, a tested alert rule and a recorded decision on the integration approach.
Choosing authentication and parsing for each endpoint type
Most REST APIs that serve operational data accept a bearer token or an API key in a request header. The Infinity data source lets you set these headers in the data source configuration, so every panel that uses that data source sends them without repeating the value in each query. Store the token in the data source secure fields rather than in a panel query, and confirm that the owning team can rotate it without editing dashboards.
- Secret location: Keep the token in the data source's secure header or secure field so it is encrypted at rest in the Grafana database, and document who owns the value.
- Dashboard JSON: Reference the data source by UID in panels. Do not paste the token into a query, a URL parameter or a panel description, because exported dashboards carry those fields.
- Least privilege: Issue a read-only key scoped to the endpoints the dashboard needs, and ask the API owner which scopes the key actually grants.
- Rotation: Test a rotation in a non-production Grafana first, then confirm that panels and alert rules recover without a restart.
- Response check: Call the endpoint with curl or a similar client, confirm the status code, and check which fields are nested under a data array before you map them.
Before charting, confirm that the header name, the token format and the response envelope match what the API documentation states, because a silent 401 or an empty array often looks like a broken panel.
OAuth 2.0 client credentials and similar token exchanges add a step: the client id and secret obtain a short-lived access token, which then has to be refreshed. The Infinity data source can be configured for these flows, but the exact settings depend on the plugin version and the identity provider, so confirm the supported grant type and token endpoint in the plugin documentation and with your identity team before you design around it.
- Secret location: Store the client secret in the data source secure fields, and limit the registered client to the minimum scopes that read the data.
- Token lifetime: Ask the identity owner for the access token lifetime and whether refresh tokens are issued, since expiry causes intermittent panel failures that look like data gaps.
- Dashboard JSON: Keep client ids and secrets out of panel queries and variables, and avoid storing token responses in dashboard variables.
- Identity provider policy: Confirm whether the provider enforces IP restrictions, MFA for interactive flows or rate limits that a dashboard refresh rate could exceed.
- Response check: Verify that the token response and the data response have the shapes you expect, including the field that holds the token and any error body returned on expiry.
Ask the identity team to name a dedicated service client for Grafana, so that a revocation or audit trail is tied to this consumer alone.
Internal services, reporting tools and older appliances often expose endpoints behind HTTP basic authentication. This is the simplest method to configure and the easiest to get wrong, because the username and password travel with every request. Use it only over TLS, and prefer a service account with read access to a narrow set of endpoints over a shared administrator login.
- Secret location: Put the password in the data source secure fields. Do not place it in the URL, since credentials embedded in a URL can appear in proxy and server logs.
- Transport: Confirm that the endpoint is served over HTTPS with a certificate your Grafana host trusts, and add the internal certificate authority to the Grafana trust store if needed.
- Account hygiene: Ask the service owner whether the account is subject to password expiry, which would silently break dashboards on a set date.
- Dashboard JSON: Export a dashboard and search it for the password and username before sharing it, because exports are a common leak path.
- Response check: Confirm that a wrong password returns a clear 401 rather than a redirect to a login page with HTTP 200, since the latter parses as HTML and produces an empty or garbled panel.
If the service cannot offer a dedicated read-only account, record that exception in your risk register and review it with the owning team.
Some operational data arrives as a file rather than an API: a nightly CSV export, a status XML published to an internal share, or a JSON file written by a batch job. Infinity can read these from a URL, so a file server or object store path becomes a data source. Files need the same credential care as APIs when they are not public, and they need stricter checks on structure because a changed column order or an added header row can shift every value.
- Secret location: If the file requires access, use the same secure field approach as the other tabs, and limit the account to the single file path.
- Parsing scope: Choose the parser that matches the format, and confirm which element or column holds the timestamp and which holds the numeric value before building any panel.
- Dashboard JSON: Use a stable file path or a versioned name in the query. Avoid hard-coding a date stamp unless the job guarantees the naming scheme.
- Structure drift: Ask the producing team whether the header row, column order, decimal separator and time zone are fixed, and record the answer as a contract.
- Response check: Load a sample file and count rows and columns against the source. For XML, confirm the root and repeated element names, and check that numeric fields carry no units or thousands separators.
A file that changes format without warning is the most common reason a static source produces plausible but wrong charts, so agree on the structure in writing.
Why alerting on Infinity data needs backend parsing and a tested query
Alert rules are evaluated by the Grafana server on a schedule, not by the browser that renders a panel. That means the parsing, filtering and field selection your alert depends on must succeed in the backend path. A query that draws a correct chart can still fail to alert if the response shape changes, a header is missing for a scheduled evaluation, or a value is only converted by a transformation that the alerting engine does not run in the same way. Treat the panel as a preview and test the alert rule itself, including how it behaves when the endpoint returns an empty array, an error status or an unexpected field type.
Shaping the data at the source endpoint is the most predictable option when you control the API. A dedicated query parameter, a summary endpoint or a small export file that already contains one numeric value per series keeps the Grafana query short and makes the alert threshold easy to reason about. The cost is that the API owner now carries a dependency on the dashboard team, and every consumer of that endpoint is affected by the change. Shaping inside Grafana, with Infinity's parsing and transformations, keeps the source untouched but moves logic into queries that others must read and maintain. Choose the option that gives the alert a stable contract, and document which one you picked.
Confirm current Infinity alerting behavior against the plugin documentation for the Grafana version you run before you rely on any Infinity query in an alert rule. Check which parsers, transformations and authentication methods the alerting engine supports, how the plugin handles timeouts and retries, and whether any behavior differs between panel queries and rule evaluation. Then run each alert rule against a test endpoint, force a failure and an empty result, and confirm that the rule reports an error state rather than silently reporting normal. Record the tested query and its expected output with the rule so the next change can be checked the same way.
Mapping JSON, CSV and XML fields to time series, tables and alert values
This table shows how common source attributes from REST, JSON, CSV and XML responses map to Grafana time fields, numeric values, labels, table columns and alert inputs. Read each row as a decision: confirm the field's type and shape in the response first, then choose the transformation that gives Grafana a clean frame. The main takeaway is that most chart problems come from unparsed timestamps or nested paths, not from the panel itself.
| Source format | Field | Grafana role | Transformation needed |
|---|---|---|---|
| JSON | Epoch or ISO 8601 timestamp | Time field | Set the column type to time, or parse the string in the Infinity query so Grafana treats it as a time field |
| JSON | Nested object path, such as data.items[0].value | Numeric value series | Enter the full path in the Infinity root or columns configuration, then confirm the field is numeric |
| JSON | Array of records | Rows in a table panel | Set the root selector to the array so each element becomes one row |
| JSON | Repeated key or category value | Label or series name | Use a string column as a dimension, then pivot or group by it in a transformation |
| CSV | Header row column with dates | Time field | Declare the column as time and confirm the timezone and format match the source |
| CSV | Numeric column with thousands separators or units | Numeric value | Strip separators or units in the query or with a calculated field before charting |
| XML | Element or attribute value | Value or label | Use the XML parser option and an XPath-style selector, then test the result in the query editor |
| Any format | Null, empty or missing value | Gap or alert no-data state | Decide whether to drop, fill or flag the row, because alert rules treat missing values differently from zero |
Securing Infinity connections and dashboards
An Infinity data source is a direct HTTP client running on your Grafana host, so its security depends on the API credentials it holds, the network path it takes, and who can change or share the queries built on it. The cards below cover those controls in the order a reviewer would check them.
Least-privilege API service accounts
Create a dedicated read-only account on each upstream API rather than reusing an administrator token. Scope it to the endpoints and tenants the dashboards actually query, and confirm that the API cannot write, delete or export beyond that scope. Ask the API owner whether the token can be rotated without changing Grafana configuration, and record who owns each account so a departing engineer does not break panels or leave an orphaned credential behind.
Secrets in secure fields
Enter API keys, bearer tokens, basic-auth passwords and client secrets into the data source's secure fields so Grafana stores them encrypted rather than in plain configuration. Avoid placing credentials in URL query strings, where they can appear in logs, browser history and proxy records. For provisioned data sources, read secrets from environment variables or a secrets manager instead of writing them into YAML files kept in version control.
Outbound access from the Grafana host
Infinity makes requests from the Grafana server, so the host needs network rules that allow only the specific API hosts, ports and DNS names the dashboards use. Block everything else outbound, including arbitrary internet destinations, so a misconfigured or malicious URL cannot be used to reach internal services. Confirm the rules with the network team and test them from the Grafana host itself, not from an administrator workstation.
Who can edit data sources
Editing a data source changes the URL, headers and authentication for every dashboard that uses it, so restrict data source administration to a small platform group and leave dashboard editors with query rights only. Review the role assignments in your access model against the Grafana authentication and access control design, and check whether your edition offers the team and provisioning controls you need. Treat any change to a shared Infinity source as a change to every panel built on it.
Hardening settings from the security guide
Apply the baseline controls in the Grafana security hardening guide: secure and SameSite cookies, a Content Security Policy, Trusted Types, hidden version information for unauthenticated users, authentication on the metrics endpoint, and domain verification against DNS rebinding. Verify each setting in the running instance by inspecting responses and configuration, since a setting that is documented but not applied gives no protection.
Reviewing panels before external sharing
Externally shared dashboards expose the results of their queries to anyone with the link, which means an Infinity panel can publish whatever the API returns, including fields you did not intend to show. Before sharing, open each panel, check the raw response and any transformations, and remove identifiers, personal data and internal hostnames. Infinity is on Grafana's list of data sources that work with externally shared dashboards, but that confirms compatibility, not that the data is safe to publish.
Common Infinity failures and how to fix them
This table pairs the failures teams most often hit with Infinity queries against REST, JSON, CSV and XML endpoints with the likely cause and the fix. Work down the symptom column that matches what you see, then confirm the fix in the panel editor before you trust the same query in an alert rule.
| Symptom | Likely cause | Fix |
|---|---|---|
| x509 or TLS trust errors in the panel | Grafana server does not trust the certificate chain of an internal API, often a private CA or a self-signed certificate | Add the internal CA to the trust store of the Grafana host or container, then confirm the data source TLS settings and restart Grafana. Avoid disabling certificate verification in production. |
| 401 Unauthorized from the endpoint | Missing, expired or misnamed credential, or a token that the data source does not send in the expected header | Check the auth method configured on the data source, confirm the token is valid for that API, and store it as a secure field rather than in the query text. |
| 403 Forbidden despite a working login | The service account lacks the API scope or role for that resource, or the query calls a path the account cannot read | Ask the API owner for a read-only account scoped to the exact endpoints the dashboards call, then test each URL with that account outside Grafana. |
| Panel times out on a slow endpoint | The endpoint computes the response on request, or returns a large payload that exceeds the query timeout | Ask the API owner for a lighter or cached endpoint, filter on the server side, and reduce the refresh rate for that panel so queries do not stack up. |
| Only the first page of results appears | The API paginates with next links, cursors or page parameters that the query does not follow | Configure pagination in the query if the plugin supports your scheme, or move the aggregation to a service that returns complete results. Compare row counts against the API's own totals. |
| CSV columns shift or parse as one column | The delimiter is a semicolon or tab rather than a comma, or the file has a byte order mark or quoted fields with embedded delimiters | Set the delimiter in the query, strip the byte order mark at the source if possible, and confirm the header row is the first line the parser reads. |
| XML fields come back empty | Namespace prefixes in the document are not included in the field path, or the root element differs from the one the query expects | Copy the exact element path from a sample response, include namespace prefixes as the document declares them, and test the path against two or three real responses. |
| Alert fires but the panel looks normal, or the reverse | Panels apply time range, transformations and reduce settings that alert rules do not, or the alert evaluates a different time window or row set | Build the alert query without panel-only transformations, set the reduce and threshold expressions explicitly, and compare the alert preview against the panel for the same period. |
| Alert rule works in the editor but not on schedule | The backend query depends on the browser session, a per-user token or a relative time value that resolves differently at evaluation | Use a service credential stored in the data source configuration, use absolute or evaluation-aware time values, and check the alert evaluation log after a scheduled run. |
When a small custom data source plugin beats Infinity
A small custom data source plugin is the better choice when the source needs logic Infinity cannot express, not merely when the endpoint is awkward. Grafana treats any data source that is not in core Grafana as a plugin, which you can install from the plugin catalog or build yourself, as described in the Grafana data sources documentation. The decision therefore starts with a short list of conditions: proprietary authentication that requires a signing flow, token exchange or session handling Infinity's configured auth methods cannot perform, very high query volume that needs connection pooling or server-side caching inside the plugin, and audit requirements that need each query tied to an identified user in a way the proxy and logs of a generic plugin cannot provide.
Test each condition against the Infinity configuration before concluding it is unmet. Confirm with the vendor or your own environment which auth methods the installed Infinity version supports, how it handles pagination and nested JSON, and whether its backend can call the endpoint through the network path you have. Build a short proof of concept against one representative query. If the query can be written as a URL, a header set and a parsing rule, Infinity is usually the right tool, and a plugin would add code to keep current. Write the list of conditions in the plugan decision record so the choice can be reviewed later.
A custom plugin adds ongoing work that is easy to underestimate. Each Grafana upgrade may change the plugin SDK or frontend APIs, the plugin must be signed for private use before Grafana will load it in production, and someone must own the security patches for its dependencies. Ask a quote to separate the one-time build from the recurring maintenance, including test coverage against each Grafana minor release you intend to run. If that recurring cost is not justified by the conditions above, keep the endpoint in Infinity and document its limits.
Questions buyers ask before connecting Infinity to internal APIs
What drives the cost of connecting Infinity to internal REST APIs?
The main drivers are the number of endpoints, how hard authentication is, how much parsing the responses need, and how many panels and alert rules depend on them. A handful of read-only JSON endpoints with a single API key is a small, bounded task. Dozens of endpoints with token refresh, paginated responses, XML or CSV with inconsistent columns, and alerting that must evaluate the same logic in the backend add effort at each step. Cost is one-time for the build and recurs only when APIs change, credentials rotate or new panels are added. Ask any quote to list endpoints, auth method, parsing rules and alerting scope separately so you can see what each one adds.
How long does a scoped Infinity integration usually take?
Duration depends on the same drivers as cost. A small set of endpoints with simple authentication and no alerting can be validated quickly, while a set with multi-step authentication, nested JSON, paginated or XML responses and alert rules needs more design, testing and review time. Because the work is fixed-scope, the timeline is agreed in writing before work starts, with each endpoint and alert listed as a deliverable. Ask for the timeline to be tied to named endpoints so progress can be checked against them.
What does our team need to provide before the work starts?
Plan to provide the following before the build begins:
- Current API documentation, including request and response examples, pagination rules and rate limits.
- Test credentials with read-only scope in a non-production environment, plus a production credential path that your security team approves.
- Network access from the Grafana server to each API, including firewall rules, proxy settings and any internal certificate authority.
- A named owner for each API who can answer questions about schema changes and who approves access.
Missing any of these usually stretches the timeline more than the technical work itself.
Can an internal team connect Infinity to our APIs without a partner?
Yes, a team with Grafana administration skills and access to the APIs can configure the Infinity data source for simple, read-only JSON endpoints by following the plugin documentation. The harder parts are secure credential handling, backend parsing that alerting depends on, and keeping queries stable when an API changes. Teams without spare capacity or without experience in API authentication often find a scoped engagement easier to plan. Compare the cost of your own time against a written scope, and decide based on how many endpoints and alerts you need in production.
What breaks most often in Infinity dashboards built on internal APIs?
The most common failures are expired tokens, changed field names or nesting, pagination that silently returns only the first page, and API rate limits that appear only under dashboard refresh load. Alert rules are affected most, because a query that renders correctly in a panel can return a different shape to the alerting engine. Build checks that compare panel output with a known value, set refresh intervals with API limits in mind, and assign an owner who is told when the upstream schema changes.
How should credentials and network access be handled for Infinity?
Use a dedicated read-only account for each API, store secrets in the Grafana provisioning or secrets configuration rather than in dashboard JSON, and restrict outbound traffic from the Grafana host to the specific endpoints required. Confirm with the API owner whether tokens can be scoped and rotated, and whether the service account is allowed to make the required calls. Review the Grafana security hardening guidance for cookies, Content Security Policy and metrics endpoint protection, since these apply to any Grafana instance that holds API credentials.
When is a small custom data source plugin a better choice than Infinity?
Choose a custom plugin when the API needs stateful sign-in flows that Infinity cannot express cleanly, when the same logic must run identically in dashboards and alerts across many panels, or when response handling is complex enough that it should be tested as code. Infinity remains the faster option for simple JSON, CSV and XML endpoints. Grafana documents that data sources not in core Grafana can be added from the plugin catalog or built yourself, so the decision is about maintenance: a custom plugin needs signing, version control, and an upgrade path with each Grafana release. Ask for a written comparison covering both options before committing.
How DeployOpen scopes and delivers Infinity integrations
DeployOpen plans, builds, tests and documents Infinity data sources inside your own infrastructure, so each REST, JSON, CSV or XML feed is scoped against the endpoints, credentials and alerting needs you already have. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory each REST, JSON, CSV and XML endpoint, its owner, update cadence and whether it is needed for dashboards, alerts or both.
- Record the authentication method for every endpoint, including token scope, rotation ownership and whether a secrets store will hold it.
- Confirm which panels need backend parsing for alert rules and which can stay on frontend transformations, and agree that split in writing.
How we build
- Install and configure the Infinity plugin on your self-hosted Grafana, with data source definitions stored as provisioning files where your process allows.
- Build queries with JSONPath, CSV and XML parsing rules, and test each one against sample responses that include empty, malformed and paginated cases.
- Assess whether a small custom data source plugin is the better option for an internal system, and document the reasoning before any code is written.
How we hand over
- Deliver a written register of each data source, its endpoint, auth method, query definitions, owners and known limits of the parsing approach.
- Provide dashboards and alert rules with verification notes showing expected values, how the rules were tested and how failures surface.
- Walk your platform and operations staff through rotating credentials, updating queries after an upstream schema change and removing a source safely.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, covering Grafana and Infinity plugin version changes.
- Review plugin releases and upstream API changes on a schedule agreed in the scope, and document any query that needs adjustment.
- Ask prospective partners to confirm plugin version compatibility with your Grafana release and how upgrades will be tested before rollout.
