Logs, and what to send when something is wrong

There is no single log on the machine, and there is no command that collects one. This page is where each kind lives, how you read it, and what to put in a report so that somebody can act on it.

Reading logs: the advanced view

The dashboard's simple view shows no logs at all — deliberately, because a log is not something you need on a good day. Turn on the advanced view first: the gear at the top right, then **Detail**. Three log surfaces appear.

• **Logs on a row of the Apps card** — the last 300 lines of that tool's own journal. This is the one to reach for when a tool will not start or is behaving oddly. A tool that has never started says so, rather than showing you an empty journal as if it were the log.
• **Log on a row of the Installation card** — what that component's install actually printed, which is where a tool that failed to install explains itself.
• **Live log**, under the same card — the machine narrating what it is doing while it does it.

The dashboard reads these on your behalf because the files are owned by root: the install logs live under /var/log/vmbox/, one file per component; each tool also writes to the system journal under a unit named vmbox-<tool>; the machine software's own unit is vmbox-agent; and there is a durable event log and an audit log under /var/lib/vmbox/. Reading any of them directly needs root on the machine, which the account your terminal lands on does not have.

Logs are bounded, and they keep one previous generation each. They are not an archive: if something happened last week and nothing has been quiet since, the lines are gone. Copy out anything you want to keep.

What does not exist

• **No vmbox logs, vmbox status or vmbox doctor.** Nobody will ask you to run one.
• **No diagnostic bundle.** There is no command that packages up the machine's state for support, so there is nothing to attach to an email.
• **No logs on this website.** Your machine's page here shows what the machine last reported about itself. It has never held a log line.
• **No request log in the gateway.** There is no record of which pages you opened.

Reporting a fault from the machine

The fastest route is **Something is wrong here** in the dashboard footer. It takes 500 characters, then opens the form on this site with your words already in it, plus this machine's name and the version it is running. The dialog says exactly what it is attaching before you press anything.

It sends nothing by itself. Your own browser carries the words here, and you press send on a page we served — the machine has no way to post a report and does not want one.

The other footer control, **Feedback and requests**, opens the same form empty and attaches nothing about the machine. Use it for an idea, a tool we do not have, or a price that looks wrong.

On a machine that reports to nowhere, both controls are hidden — there is no form to send you to.

Reporting a fault from this site

• Your machine's page has **Tell us what is wrong, or missing**, which carries the machine and the version it reported.
• The contact page has the same form, and it needs no account — anybody can file a bug or a request, signed in or not.
• Anything about your bill or a refund goes through the same form — say which, and quote your order code. The contact page also lists our addresses, but use the form if you can: the addresses are published as links, and the layer in front of this site currently hides them behind a click, so an address read off the page may not be usable.

There is no ticket number and no automatic reply. A report lands in the same list as every other outstanding one and a person reads it; if it needs an answer, the answer comes by email.

What to put in it

1. **Your order code.** It is the monospace heading on your machine's page here, and it covers the whole arc from the order to the lease. The machine's own dashboard does not know it.
2. **What you did, what you expected, and what happened instead.** In that order, and specifically — "n8n's editor showed 502 after I pressed Start" is worth more than "n8n is broken".
3. **Roughly when**, so the right stretch of log can be found.
4. **The name of the tool**, if it is one tool. Faults are per tool far more often than per machine.
5. **Anything the log said**, pasted. The advanced view puts it in front of you, and a pasted line is worth more than a description of one.

What we can already see

Your machine posts a short report about once a minute: its software version, how many tools are ready or failed and which ones by name, CPU, memory, disk, uptime, whether security updates are waiting, its hostname and architecture, when its certificate expires, a count of open dashboard sessions, and the fingerprints of the SSH keys it trusts.

There is no file content in it, no code, no environment, no command history and no keystrokes, and it never contains a log. Trust and security lists the whole payload field by field. So a report tells us a tool has failed; it does not tell us why, which is what the log in front of you is for.