Support and tickets
Where to reach our engineers, what to put in a ticket so the first answer is useful, and what to check before opening one.
How to reach us
| Channel | Use it for |
|---|---|
| Ticket in the client area | Anything technical or billing related. It is attached to your account and to the service |
| Contact form | Pre-sales questions and quotes |
| +33 1 84 73 40 75 | Urgent matters, during business hours |
| contact@bullionet.com | When you cannot reach the client area |
Our engineers answer during business hours, with on-call coverage for critical incidents. Tickets from the client area reach the person who can act on the machine, which email to a generic address does not.
The Discord community
discord.gg/Kxqs7HF3A7 is where our customers talk to each other: a question about a distribution, a configuration someone has already solved, a rough edge on the panel. Answers come fast, and often from someone who hit the same thing last month.
It is not a support channel. Nothing reported there is tracked, nobody is on call, and an incident on your server belongs in a ticket. Use both: Discord for "how do I", a ticket for "it is broken".
What to put in a ticket
The first answer is only as good as the ticket. Include:
- The service identifier and the IP address. An account can hold several servers.
- Timestamps with the timezone. "Yesterday around 3pm CEST" is workable; "this morning" is not.
- What you observe, and from where. Error message, exit code, the exact command.
- An MTR in both directions for anything network related:
mtr -rwzbc 100 203.0.113.10 # from your side towards the server
mtr -rwzbc 100 <your-ip> # from the server towards you- What changed. A kernel upgrade, a new firewall rule, a deployment. This is the single most useful line in a ticket.
- What you already ruled out. It stops the thread from repeating your own steps back to you.
Good to know
For a network problem, run the MTR before the reboot. A reboot that fixes the symptom without evidence leaves you with the same incident next week.
Check these first
- The looking glass for the return path from our network.
- The out-of-band console to tell a dead machine from an unreachable one.
- Your own firewall rules, if the server answers on the console but not on the network.
What counts as critical
A machine down, an array degraded, a network loss on a production service: report those immediately, by ticket and by phone during business hours. Say plainly that production is down. A question about a configuration or a quote is not critical, and mixing the two in one ticket slows both.
Reviewed on September 1, 2026