What evidence should I record during a server incident?
Keep a shared, factual timeline so responders can connect symptoms with changes and avoid repeating ineffective actions. Record observations separately from hypotheses and note the source of each fact. The evidence should support recovery now and a useful review afterward.
Before you start
- An incident owner, a consistent time reference and access to authorised monitoring or logs.
Instructions
1. Establish the incident record
Record start or detection time, affected services, user impact and the last known healthy state. Use UTC or an explicitly stated time zone. Include service identifiers and relevant request or correlation IDs, while avoiding passwords, tokens and unnecessary personal data.
2. Log actions and results
For each intervention, record who acted, the exact scope, time, reason and observed result. Note whether a control-panel operation was requested, accepted or completed. Britixo’s VPS Activity view can help identify operation times, but the final service state still needs a separate check.
3. Preserve useful bounded evidence
Capture the relevant metric interval, selected error messages and configuration-change references using the approved evidence process. Keep sensitive material restricted and redact extracts shared in tickets. After recovery, document the validation, remaining uncertainty and actions needed to prevent the same failure.
Check the result
- Another responder can reconstruct the sequence and distinguish facts from assumptions.
- The recovery claim is supported by application checks and a defined observation period.
Troubleshooting
- Logs appear to show events in the wrong order
- Compare time zones, clock synchronisation and collection delays before inferring causation. Keep original timestamps and explain any conversion used in the timeline.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.