> For the complete documentation index, see [llms.txt](https://docs.ipcheck.ing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ipcheck.ing/developer/contributing/reporting-issues.md).

# Reporting Issues

All bugs and feature requests go to [GitHub Issues](https://github.com/jason5ng32/MyIP/issues). The repository ships two templates — a bug report and a feature request — and picking the right one saves everyone a round trip.

## Before you file

{% hint style="info" %}
Most reports about self-hosted deployments turn out to be configuration issues, not bugs. Check these first.
{% endhint %}

1. **Search existing issues**, open and closed. Your problem may already be reported, answered, or fixed on `dev`.
2. **Read the** [**FAQ**](/developer/reference/faq.md)**.** It covers the common deployment and configuration problems.
3. **Confirm your setup.** MaxMind is required — see [MaxMind Setup](/developer/getting-started/maxmind-setup.md). Several features depend on optional API keys; see [Optional API Keys](/developer/configuration/optional-api-keys.md).
4. **Try the latest version.** The bug may already be gone.

## Filing a bug report

Use the **Bug report** template. It is labelled `bug` automatically. The template asks for the following.

### Environment

* Operating system
* Browser, if applicable
* Node version
* Vite version
* Vue 3 version
* Docker version, if applicable
* Deployment method — Vercel, Docker, or Node
* Environment variables, **with all secrets removed**
* Any other relevant software versions

{% hint style="danger" %}
Never paste API keys, tokens, or MaxMind credentials into an issue. Redact them. If you have already leaked one, rotate it.
{% endhint %}

### Description and steps to reproduce

A clear description of the bug, followed by numbered steps that reproduce it. Reproduction steps are the single most useful part of a report.

### Expected vs actual behavior

What you expected to happen, and what actually happened. Screenshots or a short screen recording help for anything visual.

### Terminal and console logs

The template calls this out as important, and it is. Include both when they apply:

* **Terminal logs** from the backend — error messages and stack traces.
* **Browser console logs** for anything that fails in the frontend.

<details>

<summary>Getting more detail out of the backend</summary>

The backend logs through a shared `pino` logger. Raise the level to capture more before reproducing:

```bash
LOG_LEVEL=debug pnpm dev
```

See [Logging](/developer/configuration/logging.md) for the other knobs, including `LOG_FORMAT` and `LOG_HTTP`.

</details>

### Optional extras

* **Additional context** — links to related issues, anything else relevant.
* **Possible solution** — if you already have an idea of the fix, describe it. If you want to write it, say so and read [How to Contribute](/developer/contributing/how-to-contribute.md) first.

## Filing a feature request

Use the **Feature request** template. It is labelled `enhancement` automatically, and it asks four things:

| Field                                   | What to write                                   |
| --------------------------------------- | ----------------------------------------------- |
| Is it related to a problem?             | The frustration behind the request, concretely  |
| Describe the solution you'd like        | What should happen, from a user's point of view |
| Describe alternatives you've considered | Other approaches, and why they fall short       |
| Additional context                      | Screenshots, mockups, links to prior art        |

Explain the user-facing benefit, not just the implementation. A request that starts from a real problem is much easier to evaluate than one that starts from a proposed API.

{% hint style="info" %}
Planning to build the feature yourself? Open the issue anyway and wait for a maintainer to confirm the direction before writing code. See [How to Contribute](/developer/contributing/how-to-contribute.md).
{% endhint %}

## Security issues are different

Do not open a normal bug report for a vulnerability. Follow the [Security Policy](/developer/contributing/security-policy.md) instead.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ipcheck.ing/developer/contributing/reporting-issues.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.