What evidence should I send when I suspect a VPS host problem?
Report what the guest and application actually experienced, with timestamps and the selected service reference. The provider needs that evidence to correlate physical-host, storage or network telemetry that is not visible inside the VPS.
Instructions
1. Describe the specific impact
State the affected service, expected behaviour, observed failure, start time, time zone and whether the issue is ongoing. Include recent authorised changes and the result of console access. Avoid labelling the cause as host failure before evidence establishes it.
2. Collect small relevant measurements
For a suspected Linux CPU scheduling problem, a short sample may be useful.
date -Is
mpstat 1 5Use this only where sysstat is installed. Pair the sample with the actual application symptom; choose disk or network evidence instead when those are the suspected resources.
3. Use the existing support conversation
In Britixo Support tickets, include the service and activity references, non-sensitive error text and a redacted diagnostic excerpt. Do not send passwords, private keys, console tokens, full environment dumps or unrelated customer data. Keep follow-up observations in the same incident thread.
Check the result
- The report identifies the exact service, time window and measurable impact.
- Diagnostics are relevant, bounded and redacted while preserving the error needed for investigation.
Troubleshooting
- Guest access is completely unavailable
- Report the console outcome, provider state and external service tests rather than claiming a guest metric you could not collect.
- The issue is intermittent
- Provide several incident windows and comparison periods so provider telemetry can be correlated.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.