Grafana Cloud k6 to Elasticsearch: How to Move Your Data
Move Grafana Cloud k6 into Elasticsearch with Airbyte. Why this destination needs Core or PyAirbyte, why you get the catalogue and not results, and how to map it.
Moving Grafana Cloud k6 into Elasticsearch gives you a searchable inventory of your performance testing estate. Once an organisation has accumulated hundreds of tests across dozens of projects, finding the one that covers a particular endpoint becomes genuinely difficult from inside the tool.
This guide covers the managed path with Airbyte. Two things shape the build, and the first is a hard blocker: this destination exists on Airbyte Core and PyAirbyte only. The second is that the connector carries your test catalogue rather than your test results.
Grafana Cloud k6 to Elasticsearch at a glance:
Why move data from Grafana Cloud k6 to Elasticsearch?
Two situations account for most of these pipelines.
The first is findability. Projects accumulate, teams organise them by service or brand or release, and after a couple of years nobody can say with confidence whether a test already exists for a given endpoint. Indexing the catalogue makes that a search rather than an archaeology exercise.
The second is governance, answering which projects exist and who owns what. Be clear about the limit before scoping anything: this carries the structure of your testing estate and not the performance data it produced. If somebody wants response time percentiles or trend analysis across runs, that lives in Grafana Cloud k6 itself and no pipeline here will retrieve it.
What do you need before you start?
Four things, and the first decides whether you can proceed at all:
An Airbyte Core or PyAirbyte deployment. The Elasticsearch destination is not offered on Standard, Plus, Pro or Enterprise Flex, which makes this a planning question rather than a configuration one. The Elasticsearch destination documentation sets out the support position.
An API token, preferably a shared one. Found under performance testing settings in Grafana Cloud. A stack token suits a pipeline better than a personal token, since a personal one ties the integration to somebody's account and stops working when they leave. The k6 Cloud source documentation covers the configuration, which is brief.
An index mapping designed for names. Test and project names are what people search on, and how you map them decides whether searching works the way anybody expects. This needs deciding before the first sync rather than after.
A plan for tests that disappear. Syncs are full refresh only, and a deleted test stops arriving without anything instructing the index to remove it. How you handle that is a real decision rather than a detail.
If your cluster restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list before you begin.
How do you build a Grafana Cloud k6 to Elasticsearch pipeline in Airbyte?
Step 1: Confirm your deployment supports this destination
Check this before anything else, because no amount of correct configuration works around it. The Elasticsearch destination is available on Airbyte Core and PyAirbyte and not on the managed tiers, so a team running Standard or above needs a different plan entirely. Establishing that in two minutes is considerably better than discovering it after the source is configured and somebody has been told a date.
Step 2: Configure the k6 Cloud source
Click Sources in the left navigation, then New Source, and select k6 Cloud, following adding a source. Supply the API token, which is the entire configuration. Three streams are available covering organizations, projects and tests, and you will almost certainly want all three since each is small and they only make sense together.
Step 3: Configure the Elasticsearch destination
Click Destinations, then New Destination, and select Elasticsearch, following adding a destination. Supply the endpoint and authentication, and point it at indexes whose mapping you created rather than letting Elasticsearch infer types from whatever documents happen to arrive first.
Step 4: Create the connection and schedule it gently
Click Connections, then New connection, select your streams and a sync mode. Only full refresh is available, so every run reads everything, which is perfectly fine on a catalogue of this size. Daily is generous, since a testing estate changes when somebody creates a project rather than continuously.
Then check that searching for a test you know exists actually returns it, because a mapping problem looks identical to an empty index until you try.
What does this connector actually carry?
Three streams describing structure: organizations, projects and tests. That tells you what exists, how it is organised and who it belongs to. What it does not tell you is how any of those tests performed, because response times, percentiles, error rates and the whole body of results a load test produces are outside this connector entirely.
That gap matters because performance data is what most people assume a k6 pipeline delivers. Somebody asking for load testing data in the warehouse almost always means results, and handing them a catalogue of test definitions is a disappointing outcome after the work is done. Say this at the start of the conversation rather than at the end of the project.
Taken for what it is, the catalogue answers real questions. Which projects exist and how are they organised, which tests have not been touched in a year, whether a test already covers the service somebody is about to write one for, and how testing coverage is distributed across teams. Those are governance questions rather than performance ones, and they are genuinely hard to answer from inside the tool once the estate is large.
How should a full-refresh catalogue land in an index?
Deliberately, because full refresh and an index do not tidy up after each other. Every sync sends the current catalogue, and a test deleted in Grafana Cloud k6 simply stops appearing in what arrives. Nothing instructs Elasticsearch to remove the document it already holds, so without a plan your index accumulates tests that no longer exist and search results point at things people cannot find.
The catalogue is small enough that the simplest answers work well. Writing into a fresh index each sync and swapping an alias across gives you a clean, correct index every time with no deletion logic at all, which is a luxury you would not have with a large dataset. Failing that, timestamp the documents and treat anything not seen in the latest sync as retired rather than deleting it, which also preserves a record of what used to exist.
Map the fields for how people search. Test and project names want to be analysed text so that searching for part of a name works, and probably a multi-field mapping so the exact name can also be matched and sorted on. Identifiers, statuses and organisation references belong as keywords, since those are filters rather than search terms. Get this right before the first sync, because changing a mapping means reindexing.
Frequently asked questions
Can I use this destination on any Airbyte plan?
No. Elasticsearch is available on Airbyte Core and PyAirbyte only, so confirm your deployment before planning anything around it.
Does this include test results and metrics?
No. The three streams cover organizations, projects and tests, meaning the structure of your estate rather than the performance data any test produced.
Why are deleted tests still in my index?
Because full refresh sends what currently exists and nothing removes what it no longer sends. Write to a fresh index and swap an alias, or mark unseen documents as retired.
Should I use a personal or a stack token?
A stack token for anything shared, since a personal one ties the pipeline to one person's account and fails when they move on.
Can I do this without writing code?
The pipeline, yes, and it is a short setup. The index mapping is configuration you write in Elasticsearch, and the alias swap is a small piece of operational scripting.
Get your Grafana Cloud k6 data into Elasticsearch
Confirm your deployment supports the Elasticsearch destination first, since Core and PyAirbyte are the only options. Then set expectations, because three streams of organizations, projects and tests describe your testing estate and not its results. Use a stack token, map names as analysed text with a keyword alongside, and handle the full refresh honestly by swapping an alias or marking unseen tests retired.
Airbyte's connector catalog includes 600+ pre-built connectors, so engineering tooling can be inventoried alongside everything else. For error monitoring into the same destination, see Sentry to Elasticsearch, and for another narrow, full-refresh source into the same destination, n8n to Elasticsearch.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.