---
title: "Discover real endpoints and generate a script | Grafana Labs"
description: "Use service telemetry when you have it, or skip this milestone and stay on the QuickPizza track. Prefer validating in the Cloud script editor."
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

# Discover real endpoints and generate a script

Discover and generate works best when k6 Script Authoring mode can query your Grafana Cloud metrics, logs, and traces for a named service you run in production or staging. QuickPizza alone does not include your internal service telemetry, so this milestone splits into two tracks.

If your best starting point is source code instead of telemetry, paste a GitHub repository URL; the mode uses the repository as its primary context first. Refer to [Add a GitHub repository as context](/docs/grafana-cloud/testing/k6/author-run/k6-script-authoring-mode/#add-a-github-repository-as-context) in the mode documentation.

## Track A — You have a service in Grafana with telemetry

Follow this arc in order. Each step ends with a quick checkpoint so you stay oriented.

### 1. Start from the service name

1. In **k6 Script Authoring** mode, prompt with the workload or service name as it appears in your environment (for example, the name you use in Kubernetes or in service labels). For example, paste a prompt like this one (replace `<SERVICE_NAME>` with a name that matches your telemetry).
   
   > Generate a k6 script for the `<SERVICE_NAME>` service.
2. Checkpoint: The reply should include a summary of endpoints drawn from your telemetry (for example HTTP methods, paths, traffic rates, and latency hints). If the summary is empty or clearly wrong, fix the name or confirm that metrics, logs, and traces for that service reach this Grafana Cloud stack before you continue.

### 2. Narrow to a small first script

1. Before you ask for a full multi-endpoint test, shrink scope. Pick one endpoint or a small set you understand well. Reply in plain language, for example, by naming the line from the summary or asking for a minimal script.
   
   > Use only the first endpoint from your summary to create a minimal k6 script.
2. Checkpoint: The draft should focus on that scope. If the script still pulls in many routes, send one more narrowing message with the exact paths you want.

### 3. Review generated structure and warnings

1. To open the k6 script editor, enter a prompt such as “Open the k6 script editor.” Select the k6 project that should hold the test. Read the top-of-file comment and any `TODO` markers in the editor. Treat `TODO` as a stop-and-decide signal, not boilerplate. `TODO` markers appear when you need to confirm a URL, payload, auth shape, or pacing value. Refer to [Open the k6 script editor](/docs/grafana-cloud/testing/k6/author-run/k6-script-authoring-mode/#open-the-k6-script-editor) and [Use the script editor](/docs/grafana-cloud/testing/k6/author-run/script-editor/).
2. Scan for checks, thresholds, `sleep` or scenario pacing, and URL grouping so you do not emit unbounded metric labels. Refer to [Use k6 Script Authoring mode](/docs/grafana-cloud/testing/k6/author-run/k6-script-authoring-mode/) for what a production-oriented draft typically includes.
3. Checkpoint: You can explain in one sentence what the script tests and what still needs your input. If you cannot, keep reviewing or use a follow-up prompt to summarize risks before you run.

### 4. Iterate with one follow-up, then run

1. Apply one change per message (for example, tighten a threshold, add `sleep`, or fix a `TODO` you just decided). For example, paste a prompt like this one.
   
   > Update the response-time check so the threshold matches what I expect for this endpoint in staging.
2. Validate with a short run from the script editor using **Create and Run**, or sync the latest draft from the chat into the editor first if the draft changed only in chat. Watch pass or fail on checks and thresholds, not only HTTP 200. Refer to [Use the script editor](/docs/grafana-cloud/testing/k6/author-run/script-editor/). If you prefer a local check instead, copy the script out and run a short `k6 run` with a small iteration count or duration.
3. Checkpoint: Interpret the result in plain terms. If the run failed, decide whether the failure is the system under test, an over-aggressive threshold, or a wrong check. Adjust the script or the threshold before you scale load.

### 5. Expand only after the first run works

1. When the minimal script behaves as you expect, add one endpoint or scenario at a time. Repeat the narrow → review → one follow-up → short run loop so each change stays reviewable.
2. Optionally attach or link an OpenAPI or Swagger spec so parameters, bodies, and checks are less placeholder-heavy. Refer to [Enrich with an OpenAPI spec](/docs/grafana-cloud/testing/k6/author-run/k6-script-authoring-mode/#enrich-with-an-openapi-spec) in the mode documentation for how to supply the spec (file, paste, URL, or internal fetch).

> Note
> 
> Gotchas (Discover and generate)
> 
> - Generated drafts do not include auth tokens, passwords, or request bodies inferred from your logs. If telemetry cannot safely supply a value, you supply it (for example via [Create and manage secrets](/docs/grafana-cloud/testing/k6/author-run/manage-secrets/) or environment variables you control).
> - `TODO` in the script means you decide before you rely on the script in CI or production load.
> - One endpoint first, then expand. Large first drafts are harder to review and harder to debug when a run fails.

> Note
> 
> Use this pattern, and replace `<SERVICE_NAME>` with a name that matches telemetry in your stack.
> 
> `Generate a k6 script for the <SERVICE_NAME> service.`
> 
> Copy and paste it only when that service sends metrics, logs, or traces to the same Grafana Cloud stack where you use Grafana Assistant.

## Track B — You only want hands-on with QuickPizza

If you stay on QuickPizza, skip the discovery prompts in track A and complete these steps.

1. Continue with the script file from [Generate a script from a plain-language prompt](/docs/learning-paths/k6-script-authoring-assistant/generate-from-prompt/).
2. Optionally refine that QuickPizza draft with follow-up prompts. For example, add thresholds, add a group label, or switch to a ramping stage. Keep one focused follow-up per message so diffs stay reviewable.
3. Proceed to the next milestone (Convert curl and Postman) when you are ready.

You now know when discovery applies and how to stay on the shared QuickPizza path when it does not. In the next milestone, you convert curl and Postman inputs into k6 code (still verifiable against QuickPizza).