Support exports

When something goes wrong and you need help from the vendor, the vendor needs numbers: how often a device fails, how long a run takes, which reasons come back. What they never need is the map of your network — the names of your devices, the addresses they answer on, the sites they sit in, the accounts used to reach them.

A support export carries the first and not the second. Every identifying value is replaced by a label drawn for that export alone, and the correspondence stays in the platform.

"error": "no transport available — api: could not read the certificate
          on qgea-redacted-hostname:443: [Errno 111] Connection refused"

Producing one

Support → New export. Choose how far back the log window goes, add a note if a ticket number will help you find it again, and produce it. Downloading the file is a separate gesture: the export is kept, and you can send it later or send it again.

Without a customer selected, the export covers the whole platform. With one selected, it covers that customer alone.

Read the timeline first

Most support questions are questions of sequence: someone edited the device, someone else enrolled an agent, the device was moved onto it, and the backup started failing. Three separate lists leave the reader recutting them by hand; one chronological stream tells the story.

12:42  audit  device.update   k7mq-…-user   q2vb-…-device   {"transport_pref": "ssh"}
13:02  audit  agent.enroll    b9xr-…-user   t4rz-…-agent    {"action": "token issued"}
13:05  audit  device.update   b9xr-…-user   q2vb-…-device   {"agent_ids": "…"}
13:10  run    backup.failed   t4rz-…-agent  q2vb-…-device   {"failure_kind": "auth"}

timeline merges audit acts and run outcomes. The other sections answer the questions it raises.

What is in it, and what is not

In the file	Not in the file
The timeline: audit acts and run outcomes, in order	Device, customer, agent, fleet and site names
Audit detail — which fields changed, never their values	Hostnames, IP addresses, domains
Which agents serve which devices, and since when	Account names, e-mail addresses, connecting addresses
Which credentials a device uses, and when one was last rotated	Any secret, key or configuration content
Counters per device: runs by result, failure reasons, durations	Anything shaped like a token or a password= value
Agent versions, enrolment age, certificate expiry, working copy fill
Schedules, platform types, transports, staleness tolerances
Failure reasons, cleaned line by line

Secrets are not pseudonymised — they are simply never read. The export is built from counters, states and the audit log; it never opens a credential, a repository key or a backed-up configuration. The audit log itself only ever records which fields an act touched, never what was written into them.

One deliberate exception: a customer's time zone is included in clear. It narrows geography a little, and it is worth it — half the schedule questions a support team answers are time-zone questions, and they cannot be answered without it.

Labels for objects that no longer exist

An act can name a device that was decommissioned since. Its name no longer matches anything the platform knows, so a text-cleaning pass would leave it readable. Labels are therefore assigned by the kind of object the act names, not by what can still be recognised — and an act about a device that still exists gets that device's own label, so the two line up in the timeline.

Resolving a label

Support replies: “the problem is on ayz-redacted-hostname.”

Support → Resolve a label. Paste it. The platform answers with the real value, a link to the object when it still exists, and — this matters — which export the label came from.

Why labels differ between two exports

The same host gets a different label in every export. That is deliberate: two reports sent six months apart must not let anyone line them up and rebuild your inventory from the overlap. Each export draws its own salt.

The consequence is worth stating plainly: a label only means something inside its own export. A label from January's report will not resolve against June's, and that is why the answer names the export.

Why a label and not a hash

A hash of the name would be simpler and would be wrong. Hashes are guessable: try core-sw-01, fw-01, sw-paris-01 against the hash and you have the name back within seconds, salt or no salt at the scale of a device inventory. A label is arbitrary — it is drawn, written down here, and carries nothing about the value it stands for.

Who can do what

Gesture	Permission	Recorded as
Produce an export, list and download	report:read	support.export
Resolve a label	device:read	support.resolve

The two are separate acts in the audit log, on purpose: producing an export re-identifies nothing, resolving a label does.