Analyze IT incidents, recurring causes, and time to recovery
Measure service-impacting incident frequency and recovery from a consistent incident lifecycle, then test recurring causes against changes and system context. Start with the what one row represents and definitions, calculate only from eligible records, and check the result against the source before using it.
The decision hiding in the data
Monitoring creates many alerts for one incident, severity changes over time, and tickets may reopen. Raw ticket counts reward alert noise and hide the customer impact of fewer but longer events.
Three ways to approach the same file
| Approach | What it answers | What remains at risk |
|---|---|---|
| Quick spreadsheet total | A narrow descriptive question | Definitions, duplicate rows, timing, and exceptions may be hidden |
| Reviewed analysis | The stated decision with reconciled evidence | Human judgment is still required for policy and action |
| Ongoing monitored workflow | The same decision across new periods | unexpected column changes and changed business rules still need review |
From the field · IT service manager
Measure service-impacting incident frequency and recovery from a consistent incident lifecycle, then test recurring causes against changes and system context.
Monitoring creates many alerts for one incident, severity changes over time, and tickets may reopen. Raw ticket counts reward alert noise and hide the customer impact of fewer but longer events.
Columns used in the example
incident_id · service · alert_id · detected_at · impact_start · restored_at · severity · change_id · cause_category · reopened_flag
Follow it with your own file
- Group related alerts under one reviewed incident and reconstruct status changes.
- Define detection, impact, mitigation, restoration, and closure timestamps separately.
- Calculate incident rate, impact duration, time to detect, and time to restore by service and severity.
- Link approved changes and postmortem causes as evidence, retaining unknown causes explicitly.
Check: Each incident must have one ordered lifecycle, negative durations are rejected, and service totals reconcile to the incident system rather than raw alerts.
What the file needs to answer
Measure service-impacting incident frequency and recovery from a consistent incident lifecycle, then test recurring causes against changes and system context.
The assumption to make explicit
A deployment near an incident is a candidate explanation, not proof of causation; review rollback, logs, dependencies, and alternative causes.
Build the result step by step
- Define the decision: Group related alerts under one reviewed incident and reconstruct status changes.
- Prepare the evidence: Define detection, impact, mitigation, restoration, and closure timestamps separately.
- Calculate the result: Calculate incident rate, impact duration, time to detect, and time to restore by service and severity.
- Review the exceptions: Link approved changes and postmortem causes as evidence, retaining unknown causes explicitly.
Before touching the file
- Measure service-impacting incident frequency and recovery from a consistent incident lifecycle, then test recurring causes against changes and system context.
- Each incident must have one ordered lifecycle, negative durations are rejected, and service totals reconcile to the incident system rather than raw alerts.
- A deployment near an incident is a candidate explanation, not proof of causation; review rollback, logs, dependencies, and alternative causes.
Where to look for exceptions
- The source files do not share one documented what one row represents or cutoff.
- The decision owner cannot trace the headline result to eligible source records.
- A deployment near an incident is a candidate explanation, not proof of causation; review rollback, logs, dependencies, and alternative causes.
Before the result leaves your desk
- what one row represents and eligible population documented
- Dates, units, currencies, and identifiers validated
- Each incident must have one ordered lifecycle, negative durations are rejected, and service totals reconcile to the incident system rather than raw alerts.
- Exceptions retained for human review
- Published result links back to its evidence
Doing these steps in Prepyr
Prepyr accepts CSV files only. Export the worksheet or table you need as a UTF-8 CSV first; workbook formulas, formatting, macros, charts, and other sheets will not be included. Describe the result you need: Analyze IT incidents recurring causes and time to recovery. Check the columns selected, preview any proposed changes, and compare the output with the source before applying or exporting it.
Prepyr steps used here: Analysis Anomalies · Insight Graph · Causal Graph · Report Drafts
A decision-ready result for “Analyze IT incidents recurring causes and time to recovery,” with its assumptions, exceptions, and source totals still visible.
Questions readers usually ask next
Can this it service manager analysis be done in Excel?
Yes for a small, stable file. Keep the source unchanged, document formulas and exclusions, and check outputs against the source.
What should not be automated?
Do not automate the final policy or business judgment. A deployment near an incident is a candidate explanation, not proof of causation; review rollback, logs, dependencies, and alternative causes.