> ## Documentation index
> The full klickops handbook index is at https://klickops.io/llms.txt
> The HTML of this page is at https://klickops.io/en/docs/support
> Language: en

# Getting help

Ask the klickops team a question from inside the product. We can already see your projects, so you never have to paste a log.

## What it is

**Get help** in the top bar opens a support request. It goes to the klickops team, and the whole conversation happens inside the product: you see the reply on your Help page, and you also get it by email.

The part worth knowing is what the request carries. klickops already knows your world, so a request records **where you were** rather than a copy of what was on your screen: the organization, the project, the workload you were looking at, and the version you were running. When we open your request we read your actual state at that moment, live. That is why there is nowhere in the form to paste a log, and why a one-sentence description is usually enough.

## When you'd use it

- Something is broken and the error message does not tell you what to change.
- You are not sure whether a setting does what you think it does.
- Production is down and you want a human on it now.

> [!Not this]
> A missing capability is a feature request, not a support request. Those go on the [roadmap](/roadmap) where other customers can vote for them, and voting is what decides the order things get built in.

## Ask for a question

1. Press **Get help** in the top bar, from whatever page you are on. Starting from the broken thing is better than starting from the dashboard, because the request then points straight at it.
2. Write one line saying what is wrong, then a few sentences of detail: what you expected, what happened instead, and when it started.
3. Pick how urgent it is. **Production is down** jumps the queue ahead of everything else, so keep it for outages.
4. Add a screenshot if there is something to see. Paste it straight from your clipboard, drag it in, or pick a file. Up to three. If you need to go and take one, minimize the composer rather than closing it: what you have written is kept.
5. Send. You land on the request, and you get an email when we reply.

## While it is open

**Get help** also lists your requests, and a dot on the button means we have answered one. Each request says whose turn it is:

| Status | What it means |
| --- | --- |
| With support | We have it and owe you a reply. |
| We replied | There is an answer waiting for you. |
| Resolved | Closed. Replying to it opens it again. |

Reply in the thread the same way you wrote the first message, screenshots included. When it is sorted, **Mark resolved** closes it, and either side can reopen it later.

## What we can see

While a request is open, support can open your project the way you see it: workloads, pods, events, logs, and the recommendations on your project's health. That is what lets us answer without a back-and-forth asking you to paste things.

Two things we cannot see. **Your secrets** are never returned by the API, to anyone, including us. And **what is on your screen**, which is exactly why the screenshot is the one attachment the form asks for.

> [!Careful]
> A support thread is visible to you and to the klickops team, and to nobody else in your organization. A colleague cannot read your requests, so if a request should be handed over, forward the reply rather than sharing the link.

## Limits and gotchas

- **A request belongs to one organization.** It picks up whichever one you are working in when you press the button. If you are in the wrong one, switch first.
- **Email is one-way.** Replying to a notification email does not reach us. The link in it opens the thread, which does.
- **Screenshots get resized.** Your browser scales them down before upload, which keeps them readable and small. Crop to the interesting part rather than sending a full 4K screen.
- **A minimized request survives a reload, its screenshots do not.** The text comes back; images have to be added again.

## Related

- [Plans and costs](/docs/billing) covers billing questions, which are usually faster to answer yourself.
- [Members and roles](/docs/members) is where you change who can do what, rather than asking us to.