Incident management

An incident is anything that interrupts a service or makes it worse: an app that won’t load, a slow network, a broken laptop. Incident management has one clear goal: get people working again, fast. Finding out why it happened is important too, but that belongs mostly to problem management. During an incident, restoring service comes first.

Incident adalah apa pun yang mengganggu layanan atau menurunkan kualitasnya: aplikasi yang tidak bisa dibuka, jaringan yang lambat, laptop yang rusak. Incident management punya satu tujuan jelas: membuat orang bisa bekerja kembali secepatnya. Mengetahui mengapa itu terjadi juga penting, tetapi itu sebagian besar ranah problem management. Selama incident berlangsung, memulihkan layanan adalah yang utama.

Key ideasKonsep kunci

• Priority = impact × urgency. One user who can’t print is low priority. A payment system down at month-end is top priority.
• Major incidents get their own playbook: a named manager, a war room or call, and regular updates to stakeholders.
• Restore first, investigate later. A workaround that gets users working now is a good result.
• Swarming beats ping-pong. Getting the right people together early is often faster than passing a ticket through support levels.
• Good records help everyone later. What happened, what was tried and what worked feed problem management and knowledge.

• Priority = impact × urgency. Satu pengguna yang tidak bisa mencetak berprioritas rendah. Sistem pembayaran mati di akhir bulan berprioritas tertinggi.
• Major incident punya playbook tersendiri: manajer yang ditunjuk, war room atau panggilan khusus, dan kabar rutin kepada stakeholder.
• Pulihkan dulu, investigasi kemudian. Workaround yang membuat pengguna bisa bekerja sekarang adalah hasil yang baik.
• Swarming lebih baik daripada saling oper. Mengumpulkan orang yang tepat sejak awal sering lebih cepat daripada mengoper tiket antarlevel support.
• Catatan yang baik membantu semua orang di kemudian hari. Apa yang terjadi, apa yang dicoba, dan apa yang berhasil menjadi masukan bagi problem management dan knowledge.

Key activitiesAktivitas kunci

A typical flow. Real work loops back and skips steps when it makes sense.

Alur yang umum. Dalam praktik, pekerjaan bisa kembali ke langkah sebelumnya atau melewati langkah tertentu bila masuk akal.

1. Detect and logFrom a user, monitoring or a supplier.
2. Categorize and prioritizeWhich service? How big is the impact, how urgent?
3. DiagnoseCheck known errors and recent changes first.
4. Escalate or swarmBring in the right skills; declare a major incident if needed.
5. Resolve and recoverFix or work around, then confirm service is normal.
6. Close and learnConfirm with users, record the fix, raise a problem if it may recur.

1. Mendeteksi dan mencatatDari pengguna, monitoring, atau supplier.
2. Mengategorikan dan memprioritaskanService mana? Seberapa besar dampaknya, seberapa mendesak?
3. MendiagnosisPeriksa known error dan change terbaru lebih dulu.
4. Eskalasi atau swarmingLibatkan keahlian yang tepat; nyatakan major incident bila perlu.
5. Menyelesaikan dan memulihkanPerbaiki atau gunakan workaround, lalu pastikan layanan normal.
6. Menutup dan belajarKonfirmasi ke pengguna, catat perbaikannya, buat problem jika mungkin terulang.

How to measure itCara mengukurnya

What each level looks likeGambaran setiap level

Use these descriptions as a quick self-check before running the full assessment. Level 3 is a strong, realistic target for most teams.

Gunakan deskripsi ini sebagai pengecekan cepat sebelum menjalankan asesmen lengkap. Level 3 adalah target yang kuat dan realistis bagi sebagian besar tim.

1. L1InitialIncidents are handled by whoever hears about them. Big outages are chaotic and nobody is clearly in charge.
2. L2RepeatableIncidents are logged in a tool, but priority is a matter of opinion and escalation depends on who you know.
3. L3DefinedA priority matrix, target times and a major incident procedure are documented and used by every team.
4. L4MeasuredRestore times are tracked against targets by priority. Every major incident has a review with actions.
5. L5OptimizedMonitoring catches most incidents first, swarming is routine, and review findings steadily cut restore times.

1. L1InitialIncident ditangani oleh siapa pun yang mendengarnya. Gangguan besar berlangsung kacau dan tidak jelas siapa yang memimpin.
2. L2RepeatableIncident dicatat di tools, tetapi prioritas ditentukan berdasarkan opini dan eskalasi bergantung pada siapa yang dikenal.
3. L3DefinedMatriks prioritas, target waktu, dan prosedur major incident terdokumentasi dan dipakai semua tim.
4. L4MeasuredWaktu pemulihan dipantau terhadap target per prioritas. Setiap major incident ditinjau dengan rencana tindak lanjut.
5. L5OptimizedMonitoring mendeteksi sebagian besar incident lebih dulu, swarming menjadi kebiasaan, dan temuan review terus memangkas waktu pemulihan.

Assess incident management in the wizardNilai incident management di wizard →

Using AIMemanfaatkan AI

• Correlation of alerts groups hundreds of monitoring events into one incident.
• Similar-incident search suggests fixes that worked last time.
• Draft status updates for users and managers during major incidents.
• Timeline summaries from chat and tickets to speed up post-incident reviews.

• Korelasi peringatan mengelompokkan ratusan event monitoring menjadi satu incident.
• Pencarian incident serupa menyarankan perbaikan yang berhasil sebelumnya.
• Draf kabar status untuk pengguna dan manajer selama major incident.
• Ringkasan kronologi dari chat dan tiket untuk mempercepat review pascainsiden.

Real-world example: an online store’s checkout outageContoh kasus: gangguan checkout toko online3 min3 menit

At 8 p.m. during a sale, checkout errors jump. Monitoring opens an incident automatically. It is classed as a major incident: high impact, very urgent. An incident manager opens a call with the payments, platform and network teams together (swarming).

Pukul 8 malam saat promo berlangsung, error di checkout melonjak. Monitoring otomatis membuat incident. Incident ini dikategorikan sebagai major incident: dampak tinggi, sangat mendesak. Seorang incident manager membuka panggilan dengan tim pembayaran, platform, dan jaringan sekaligus (swarming).

The change schedule shows a payment library was updated at 7:40 p.m. Rolling it back restores checkout in 25 minutes. A problem record is raised to find out why the update failed, and customers get a short apology banner.

Change schedule menunjukkan library pembayaran diperbarui pukul 7.40 malam. Mengembalikannya ke versi sebelumnya memulihkan checkout dalam 25 menit. Problem record dibuat untuk mencari tahu mengapa pembaruan itu gagal, dan pelanggan mendapat banner permintaan maaf singkat.

Common pitfallsJebakan umum

• Hunting for the root cause while users stay down. Restore first.
• Everything is "high priority". Without a shared matrix, priority means who shouts loudest.
• Silence during major incidents. Stakeholders fill the gap with rumours.
• Closing tickets without confirming with the user.

• Mencari penyebab utama sementara pengguna masih terganggu. Pulihkan dulu.
• Semuanya "prioritas tinggi". Tanpa matriks bersama, prioritas berarti siapa yang paling keras berteriak.
• Diam saja selama major incident. Stakeholder akan mengisi kekosongan dengan rumor.
• Menutup tiket tanpa konfirmasi ke pengguna.

Related practicesPractice terkait