Server failure: the incident opens before anyone calls
At 2 a.m. the database server disk fills up and the booking service stops. Nobody has reported it yet, but monitoring knows. This journey shows how the incident starts from the alert and how the on-call engineer gets everything needed.
The journey, step by step
Click any step or use the buttons to see the ticket status.
- Monitoring alert
"Disk 100%" sent via integration.
Monitoring - Automatic incident
Critical incident linked to the server asset; repeat alerts deduplicated.
System - On-call notified
SMS and call per the on-call rota.
Assignment rule - Full context
Server, dependent services, and a log-policy change made yesterday.
Majed - Recovery
Logs cleaned, service restored.
Majed - Alert clears
Metric back to normal updates the incident; fix documented.
System - Review
Problem record links the fault to the change; a change request fixes the policy.
Infra manager
Before and after
| Aspect | Without a system | With TixDesk |
|---|---|---|
| Detection | When users call | From the alert |
| On-call | Searching for a number | Notified by rota |
| Context | Several systems | Asset and changes in the ticket |
| Repeat alerts | Dozens of messages | One incident |
| Prevention | Rarely | Problem and change |
Features used in this journey
Integrations
Monitoring.
Incident management
The incident.
Assignment & on-call
On-call.
Asset management
The server.
Change management
The cause.
Problem management
Prevention.
Questions about this case
Which monitoring tools can connect?
Any that send alerts via webhook, email or API.
Does the incident close automatically?
It can update automatically on recovery; we recommend the engineer documents the fix.
See the journey on your requests
We apply this case with your details in a live demo.
- A scenario from your reality
- Your teams and policies
- Direct answers