The support ID on an error message

Sometimes the panel refuses something. Usually there is one sentence you can act on: an address that is not valid, a package that is full, a server that is busy for a moment. But sometimes that sentence is not enough — it says you may not do something, and you are quite sure that you should be allowed to.

Underneath those messages there is a small line:

Support ID Rk5t2wQfMz0

That is the only thing you need to pass on.

What it is

Every request this panel handles gets its own identifier. That identifier is in the answer your browser received, in the audit log next to the entry about what you did, and in the panel's own log — on the exact line where the panel wrote down why it refused. You deliberately do not get to see that last part: for some refusals the explanation is itself sensitive (which step of a sign-in check failed, for instance).

The support ID is the key between those three. Whoever looks into your report does not have to search for it; they look it up.

What to do with it

Send it along with your report, together with what you were trying to do. A report with a support ID can usually be found in minutes; a report without one is a search through everybody's day.

There is a copy button next to it, because eleven characters is exactly the length at which people mistype.

Is it secret?

No. It is not a password and not a key: it gives nobody access to anything. It names one request, and nothing more. It is fine to put it in an e-mail or a ticket.

Why is it not always there?

A message about a field you filled in yourself — "this is not a valid e-mail address" — has no support ID. The form is already pointing at what to change, and an identifier underneath would only distract. If it appeared everywhere, people would learn to read past it, including under the messages where it matters.

For administrators: looking an ID up

In the panel: paste the support ID into the search box of the Audit log. That search covers this identifier too, so you get the entry for exactly that request.

On the panel machine you can collect everything about one request into a single file:

corecp-panel support bundle --config /etc/corecp-panel/panel.yaml \
    --request-id Rk5t2wQfMz0 --out /root/support-Rk5t2wQfMz0.tar.gz

That file holds the audit entries and the log lines of that one request. What else is in it, and why it is safe to send, is in Sending diagnostics.

See also

• Sending diagnostics — the full diagnostic bundle, for administrators.
• Checking the audit log — who did what, and when.