# Problem reports: tell AllsWeb what went wrong > Source: https://www.allsweb.com/sixpanel/docs/problem-reports > Markdown for agents: https://www.allsweb.com/sixpanel/docs/problem-reports.md > Publisher: AllsWeb (www.allsweb.com) Part of: SixPanel documentation **What this page is for.** When something in SixPanel itself goes wrong, a report on allsweb.com is how it gets fixed in the next release. This page explains how to send one, what it carries, what never leaves your server, and how Tia sends the ones she finds by herself. **You need** - To be logged in to the panel (**[First login](https://www.allsweb.com/sixpanel/docs/first-login)**) — or, when the panel itself is down, root on the server over SSH (see [When the panel itself is down](#when-the-panel-itself-is-down)). - Nothing else. A panel that is not linked to an AllsWeb account can still send reports; they belong to this server. Linking it (**Settings → AllsWeb account**) also shows them under **Support** on allsweb.com. --- ## Send a report The **flag** button at the top of every page opens **Report a problem**: 1. **What happened?** — what you did, what you expected, and what happened instead. The first line becomes the ticket's title. 2. **Kind** — *Something is broken*, *A question*, or *An idea or a missing feature*. 3. **Attach this server's diagnostics** — on by default. See [What a report carries](#what-a-report-carries). 4. **Preview what is sent** — shows the exact JSON AllsWeb would receive, after the masking. Nothing is sent by previewing. 5. **Your email for the reply** — filled in with your alert email (**Settings → Alerts**). Leave it empty to read replies in the panel only. **Send report** answers with the ticket number and a link to it on allsweb.com. If AllsWeb already has the same problem open, your report is added to that ticket and the panel says so. If AllsWeb cannot be reached at that moment, nothing is lost: the report is saved on this server and sent by itself as soon as AllsWeb answers (see [Reports waiting to be sent](#reports-waiting-to-be-sent)). ## Report a failed job When a job ends **failed**, its log shows a **Report this** button. It opens the same dialog with the job already attached — its steps, the step that failed and the end of its log — so you only have to say what you were trying to do. ## When the panel itself is down The worst moment to need a report is when the panel cannot take one: its page will not load, or it will not start at all. The server's command line sends the same report: ``` sudo sixpanel report "the panel stopped after the update" ``` It works whether the panel is running or not. A panel that is running collects the report itself; a stopped one is read from disk, and anything only a running panel knows — its health verdict — is marked *panel not running* instead. On top of what the dialog attaches, it always includes `systemctl status sixpanel`, the panel's last 300 journal lines and, when the panel has failed, how its last run ended. The masking is the same as the dialog's. It prints a summary of what will be sent and where, and asks before it sends: - **`--preview`** prints the whole masked report as JSON and stops. Nothing is sent. - **`--yes`** sends without asking. When it is sent you get the ticket number and its link. If AllsWeb cannot be reached, the report is saved in the panel's outbox, and the command says so. The panel sends it by itself once it is running and AllsWeb answers — you do not type it again. See [The command line](https://www.allsweb.com/sixpanel/docs/cli) for the rest of the `sixpanel` tool. ## What a report carries With diagnostics attached, a report holds what a fix needs, read at the moment you send it: - **The panel** — version, build, release channel, architecture, how long it has been running, its memory use. - **The server** — the operating system, CPU, memory, disk space, and the versions of PHP, MariaDB, Redis, nginx and Node.js. - **The panel's services** — the state of every unit the panel manages, and any unit that has failed. - **The last health check** — the verdict and the rows that are not green. The panel does not start a new check to make a report. - **Jobs** — the job the report is about (its last 200 log lines) and the five most recent failed jobs (their last 50 lines each). - **The panel's recent errors** — its own last 50 exceptions and error answers, with where in the panel's code they happened — and the panel's own log. - **Configuration tests** — what `nginx -t` and `php-fpm -t` say right now. - **The project or website** you were looking at — its kind, framework, versions and how many domains it has. - **A few settings** — whether a panel domain is set, whether Cloudflare and alert mail are connected, and the release channel. Yes or no, never the values. A report is kept under 1.5 MB. When there is more, the oldest log lines are dropped first, and the report says what was cut. ## What never leaves your server Everything is masked by the panel **before** it is sent, so you do not have to trust anyone else to do it: - **Passwords, keys and tokens** — every one the panel stores (database passwords, Cloudflare tokens, storage keys, mail passwords, the panel's own AllsWeb token), the values in your apps' `.env` files whose names say they are secret, `Bearer` headers, connection strings such as `mysql://user:…@host`, private keys, and long random strings that look like keys. They read `****`. - **The panel's address** — the secret entry path in your panel's URL reads ``. - **Email and IP addresses** — shortened to their shape: `owner@example.net` reads `ow***@ex***.net`, `203.0.113.7` reads `203.*.*.*`. Enough for a reader to see that it was an address, never which one. What you type yourself is sent as you wrote it, except that a password or key in it is masked too. **Preview what is sent** is there so you can check all of this before anything leaves. ## Tia's reports Tia watches for problems that are **SixPanel's own fault** and reports them with the same diagnostics: - an error in the panel's own code — while it answered a page, ran a job, or in the background; - a configuration the panel wrote that nginx or PHP-FPM refuses to load; - an automatic repair that keeps failing, so the panel has stopped trying. She also reports **a coding program that no longer fits**. AI Coding tries every new version of the coding program it runs (Claude Code, Codex) before it uses it. When a new version does not pass that trial — or says something this SixPanel does not know yet — she tells AllsWeb, so the next SixPanel update fits it. Your sessions are not affected: the version you have stays in use. This report is smaller than any other. It holds the panel's version and build; the program's name, version and channel; each check that failed, with what was expected and what came; and the names of the parts SixPanel did not know. No project, no conversation, no file and no log is in it. She never reports a problem that is not the panel's: errors in your app's code, your DNS, your git access, Let's Encrypt limits, a full disk, or the network. Those are yours to see — on **Health**, in the job's log, or in your alert email — not ours to fix in a release. Limits, so a problem that repeats cannot turn into a flood: one problem is reported at most once a day, and she sends at most ten reports a day in all. Each report she sends is listed in **Settings → Problem reports** (marked **Tia**) and on the **[Activity](https://www.allsweb.com/sixpanel/docs/activity)** page. To stop it, turn off **Settings → Problem reports → Let Tia send problem reports by herself**. You can still send reports yourself — and when a coding program failed its trial, the **AI Coding** page then offers **Send this report**. Tia's reports need no AI provider and no SixPanel Pro: finding these problems is ordinary code, not a model. ## Follow a report **Settings → Problem reports** lists every report this panel sent — yours and Tia's — with its ticket number, who sent it, its status, and when AllsWeb last replied. The status is asked from AllsWeb each time you open the tab. **Open** shows the conversation with AllsWeb support, and you can reply from there. Replies are also on allsweb.com, through the ticket's link. How fast a person answers depends on your support plan, shown in **Settings → AllsWeb account**. ## Reports waiting to be sent A report made while AllsWeb could not be reached waits in **Settings → Problem reports → Waiting to be sent**. The panel retries by itself — after a minute, then less and less often, up to every six hours — for seven days; after that the report is dropped and the drop is written to **Activity**. - **Send now** tries all of them at once. - **Discard** removes one without sending it. A report that `sudo sixpanel report` could not send while the panel was stopped joins this list when the panel starts. A waiting report is kept as a file only the panel can read (`/opt/sixpanel/data/panel/reports/outbox/`), already masked.