Nonaktifkan WP-Cron dan Gunakan System Cron

Apa itu wp-cron dan mengapa system cron menggantikannya

WP-Cron adalah penjadwal tugas bawaan WordPress, dan hanya berjalan ketika seseorang meminta halaman. Tidak ada komponen di dalam WordPress yang berjalan sendiri. Pada setiap permintaan yang tidak dilayani dari cache, WordPress membaca daftar tugas terjadwal. Jika ada tugas yang waktunya telah tiba, WordPress mengirim permintaan HTTP kedua ke dirinya sendiri di /wp-cron.php untuk menjalankan tugas tersebut. Dengan memindahkan tugas itu ke system cron, Anda mendapatkan satu eksekusi yang dapat diprediksi pada jadwal tetap, baik situs menerima seribu pengunjung pada menit tersebut maupun tidak menerima pengunjung sama sekali.

Dua baris menjalankan proses sebenarnya: sebuah konstanta di wp-config.php dan entri crontab. Bagian lain dalam panduan ini menjelaskan hal-hal yang tidak ditunjukkan oleh kedua baris tersebut. Hal itu mencakup pengguna yang harus menjalankan tugas, cara membuktikan bahwa event terjadwal benar-benar berjalan, serta tiga cara konfigurasi ini dapat gagal tanpa menampilkan apa pun pada situs.

Contoh menggunakan /srv/www/example.com sebagai direktori WordPress dan www-data sebagai pengguna web server. Ganti path dan pengguna tersebut dengan milik Anda di semua bagian.

Biaya cron pada situs sibuk dipicu oleh pengunjung

Setiap permintaan yang tidak berasal dari cache harus membayar biaya pemeriksaan ini. WordPress memuat opsi cron, membandingkan timestamp, lalu saat ada tugas yang jatuh tempo, WordPress memanggil spawn_cron(). Fungsi ini mengirim permintaan loopback non-blocking ke /wp-cron.php. Pengunjung tidak menunggu hasilnya. Namun, satu worker PHP tetap digunakan. Pada VPS kecil yang menjalankan PHP-FPM dengan pm.max_children = 5, satu tugas terjadwal yang lambat dapat menggunakan seperlima kapasitas PHP selama proses tersebut berlangsung. Tugas ini kemungkinan besar dipicu pada menit tersibuk karena pada saat itulah pemuatan halaman paling banyak terjadi.

WordPress membatasi duplikasi. WordPress mengambil lock dengan masa berlaku WP_CRON_LOCK_TIMEOUT, yaitu 60 detik secara default, sehingga pengunjung yang mengakses secara bersamaan tidak masing-masing memulai satu proses. Lock tersebut membatasi duplikasi. Namun, lock tidak memindahkan pekerjaan keluar dari jalur permintaan.

Hitung seberapa sering proses ini berjalan di server Anda sendiri sebelum memutuskan bahwa dampaknya penting. Setiap loopback muncul dalam access log web server:

sudo grep -c 'wp-cron.php' /var/log/nginx/access.log

Apache menulisnya ke /var/log/apache2/access.log. Jumlah hingga ribuan kali per hari merupakan biaya yang nyata. Angka seperti ini sebaiknya diukur pada server Anda sendiri, bukan dibaca dari artikel, sama seperti Anda akan melakukan benchmark VPS sebelum dan sesudah perubahan lain.

Caching mengubah situasinya. Jika page cache menyajikan sebagian besar permintaan sebagai HTML statis, PHP tidak berjalan untuk permintaan tersebut sehingga pemeriksaan cron tidak terjadi. Situs sibuk dengan caching yang baik mulai berperilaku seperti situs sepi di bawah ini.

Pengunjung mana yang memicu cron hingga bermasalah pada situs yang sepi

Tanpa pengunjung, tidak ada cron. Situs yang hanya menerima beberapa kunjungan per hari menjalankan tugas terjadwal beberapa kali per hari, pada waktu acak ketika kunjungan tersebut terjadi.

Gejalanya selalu serupa. Pos yang dijadwalkan pada 09:00 tetap berada dalam daftar pos dengan status Missed schedule sampai seseorang memuat halaman. Plugin pencadangan melewatkan pencadangan malam. Pemeriksaan pembaruan terlambat, sehingga dasbor tidak menampilkan pembaruan apa pun meskipun rilis keamanan sudah tersedia. Email pesanan, pemberitahuan perpanjangan, dan peringatan kedaluwarsa terkirim terlambat.

Tidak satu pun masalah ini mencatat error. Dari sudut pandang WordPress, tugas tersebut tidak pernah terlambat karena tidak pernah dijalankan.

Langkah 1: nonaktifkan pemicu visitor di wp-config.php

Buka /srv/www/example.com/wp-config.php dan tambahkan konstanta berikut:

define( 'DISABLE_WP_CRON', true );

Letakkan konstanta tersebut di atas baris /* That's all, stop editing! Happy publishing. */, karena baris tepat di bawah komentar itu memerlukan wp-settings.php, dan wp-settings.php adalah lokasi WordPress memasang pemeriksaan cron pada init. Konstanta yang ditetapkan setelah require tersebut terlambat untuk mengubah apa pun. File akan terlihat benar, tetapi pemicunya tetap berjalan.

Pastikan baris tersebut berada di lokasi yang Anda maksud:

grep -n "DISABLE_WP_CRON\|stop editing" /srv/www/example.com/wp-config.php

Konstanta ini tidak menghentikan penjadwalan event. Plugin tetap menambahkan job ke queue seperti sebelumnya. Konstanta ini hanya menghentikan page load agar tidak menjalankan queue tersebut. Akibatnya, queue tidak akan berjalan lagi sampai Anda menyelesaikan langkah 3.

Konstanta ini juga tidak memblokir request langsung ke /wp-cron.php. Siapa pun tetap dapat meminta URL tersebut. Biasanya hal ini tidak berbahaya karena file tersebut hanya menjalankan pekerjaan yang sudah waktunya dijalankan. Pemblokiran URL ini di konfigurasi web server bersifat opsional. Jika Anda memblokirnya, fallback curl di dekat akhir panduan ini juga tidak akan berfungsi.

Langkah 2: instal WP-CLI

WP-CLI adalah alat baris perintah resmi untuk WordPress. Alat ini memerlukan biner baris perintah PHP, yang merupakan paket terpisah dari modul PHP milik server web.

php -v
sudo apt install -y php-cli

Instal WP-CLI dari build phar. Metode ini direkomendasikan dalam panduan instalasi resmi:

cd /tmp
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
wp --info

php wp-cli.phar --info menampilkan path biner PHP, versi PHP, dan versi WP-CLI. Jika ketiganya ditampilkan, phar berfungsi. Per Agustus 2026, panduan instalasi menetapkan PHP 7.2.24 sebagai versi minimum, sedangkan Ubuntu 24.04 menyertakan PHP 8.3. Jadi, server saat ini sudah jauh di atas batas tersebut. Perbarui nanti dengan sudo wp cli update.

Jalankan WP-CLI sebagai user situs. Jangan pernah menjalankannya sebagai root:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com core version

Sebagai root, WP-CLI menolak untuk start:

Error: YIKES! It looks like you're running this as root.

WP-CLI menyarankan --allow-root. Jangan gunakan cara tersebut di sini. Alasannya dijelaskan pada mode kegagalan pertama di bawah.

Perhatikan juga bahwa sudo -u www-data -i tidak berfungsi karena login shell akun tersebut adalah /usr/sbin/nologin dan Anda mendapatkan This account is currently not available.. Meneruskan perintah langsung ke sudo -u melewati login shell sehingga perintah berjalan dengan baik.

Sekarang pastikan WordPress sendiri membaca konstanta dari langkah 1:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com eval 'var_dump( DISABLE_WP_CRON );'

Perintah tersebut mencetak bool(true). Error fatal tentang konstanta yang tidak didefinisikan berarti baris define() tidak tercapai. Biasanya, baris tersebut berada setelah perintah require.

Langkah 3: tambahkan entri cron sebagai user yang tepat

User yang tepat adalah user yang memiliki file yang ditulis oleh PHP. Periksa kedua sisinya:

stat -c '%U %G' /srv/www/example.com/wp-content/uploads
grep -E '^(user|group) = ' /etc/php/8.3/fpm/pool.d/www.conf

Pada instalasi Ubuntu default, keduanya menjawab www-data. Jika Anda memberikan PHP-FPM pool tersendiri kepada situs tersebut dengan user tersendiri, seperti yang biasanya digunakan dalam penyiapan per situs pada stack LAMP di Ubuntu 24.04, gunakan user tersebut untuk semua langkah di bawah.

Buat direktori log yang dapat ditulis oleh user tersebut:

sudo install -d -o www-data -g www-data -m 750 /var/log/wp-cron

Edit crontab user tersebut:

sudo crontab -u www-data -e

Tambahkan satu baris:

*/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-example.lock /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now >> /var/log/wp-cron/example.log 2>&1

Mari uraikan. */5 menjalankannya setiap lima menit. flock -n mengambil file kunci dan langsung berhenti jika proses sebelumnya masih memegang kunci tersebut. /usr/local/bin/wp adalah path absolut yang diperlukan cron. --path memungkinkan perintah berjalan dari direktori kerja mana pun. --due-now hanya menjalankan event yang waktunya sudah tiba, bukan setiap event dalam antrean. Redirect tersebut mengirim output normal dan error ke satu file yang dapat Anda baca.

Dalam praktiknya, redirect tersebut wajib digunakan. Cron mengirim output sebuah job melalui email kepada user-nya, tetapi sebagian besar image VPS tidak memiliki mail transfer agent yang terpasang. Cron kemudian mencatat (CRON) info (No MTA installed, discarding output) dan membuang output tersebut. File log menyimpan bukti eksekusinya.

Periksa file yang disimpan:

sudo crontab -u www-data -l

Untuk beberapa situs, gunakan satu baris untuk setiap situs dengan menit yang dibuat berbeda agar semuanya tidak mulai bersamaan:

*/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-one.lock /usr/local/bin/wp --path=/srv/www/one.example.com cron event run --due-now >> /var/log/wp-cron/one.log 2>&1
2-59/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-two.lock /usr/local/bin/wp --path=/srv/www/two.example.com cron event run --due-now >> /var/log/wp-cron/two.log 2>&1

Log akan terus bertambah jika tidak dirotasi. Tulis /etc/logrotate.d/wp-cron:

/var/log/wp-cron/*.log {
    weekly
    rotate 4
    missingok
    notifempty
    compress
    create 640 www-data www-data
}

Periksa sintaksnya tanpa menjalankan apa pun: sudo logrotate --debug /etc/logrotate.d/wp-cron.

Langkah 4: pastikan event terjadwal benar-benar dijalankan

Baris crontab yang berhasil disimpan tidak membuktikan apa pun. Lakukan pemeriksaan dari yang paling sederhana hingga pemeriksaan yang benar-benar memastikan hasilnya.

Pertama, apakah cron memulai perintah tersebut? Cron mencatat log ke journal pada unitnya sendiri:

journalctl -u cron.service --since "15 min ago" | grep wp

Entri yang normal terlihat seperti ini, dengan timestamp dan nama host di bagian awal dihilangkan:

CRON[24913]: (www-data) CMD (/usr/bin/flock -n /run/lock/wp-cron-example.lock /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now >> /var/log/wp-cron/example.log 2>&1)

Baris tersebut berarti cron memulai perintah Anda sebagai www-data. Baris itu tidak menunjukkan apakah perintah berhasil.

Kedua, apakah WordPress menjalankan sesuatu? Baca file log:

sudo tail -n 20 /var/log/wp-cron/example.log

WP-CLI mencetak satu baris untuk setiap event, lalu jumlah totalnya:

Executed the cron event 'wp_version_check' in 0.418s.
Success: Executed a total of 2 cron events.

Error ditulis ke file yang sama. Inilah tujuan 2>&1. Pada sebagian besar proses, tidak ada event yang jatuh tempo sehingga hanya sedikit data yang ditulis. Karena itu, baca file setelah proses yang Anda ketahui memiliki pekerjaan yang menunggu.

Ketiga, buktikan alurnya secara menyeluruh. Jadwalkan event penanda dan amati hingga event tersebut hilang:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event schedule wp_cli_cron_check now
sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event list --fields=hook,next_run_relative --format=csv | grep wp_cli_cron_check

Tunggu satu interval, lalu jalankan kembali perintah untuk menampilkan daftar. Hook tersebut sudah hilang karena event satu kali dihapus dari antrean saat dijalankan. Tidak ada plugin yang mendaftarkan callback pada nama hook tersebut, sehingga menjalankannya tidak melakukan hal lain pada situs. Jika hook masih tercantum setelah dua interval, antrean tidak sedang dijalankan. Dua pemeriksaan pertama akan menunjukkan apakah masalahnya ada pada cron atau WP-CLI.

Jangan gunakan wp cron test untuk pemeriksaan ini. Perintah tersebut memeriksa apakah pemanggilan oleh pengunjung dapat memulai proses, dan menghasilkan error jika DISABLE_WP_CRON bernilai true. Pada server yang dikonfigurasi dengan benar, error tersebut adalah output yang diharapkan, bukan kegagalan.

Alternatif timer systemd

Jika pekerjaan terjadwal lain pada server sudah menggunakan service dan timer systemd, tempatkan WordPress di sana juga. Setiap eksekusi akan tercatat dalam systemctl list-timers, dan output dikirim ke journal, bukan ke file yang harus Anda rotasi.

Tulis /etc/systemd/system/wp-cron-example.service:

[Unit]
Description=Run due WordPress cron events for example.com

[Service]
Type=oneshot
User=www-data
Group=www-data
ExecStart=/usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now

Kemudian /etc/systemd/system/wp-cron-example.timer:

[Unit]
Description=Run WordPress cron for example.com every 5 minutes

[Timer]
OnCalendar=*:0/5
AccuracySec=30s
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now wp-cron-example.timer
systemctl list-timers wp-cron-example.timer
journalctl -u wp-cron-example.service -n 20

Systemd tidak akan menjalankan dua salinan service yang sama secara bersamaan, sehingga versi ini tidak memerlukan flock. Persistent=true membuat systemd mengejar eksekusi yang terlewat saat mesin mati, yang tidak dapat dilakukan oleh entri crontab.

Pilih crontab atau timer. Menjalankan keduanya pada situs yang sama berarti antrean diproses dua kali, dan eksekusi duplikat pada pekerjaan email atau pesanan akan terlihat oleh pelanggan Anda.

Mengapa cron job tidak boleh berjalan sebagai root

Ini adalah cara pertama dari tiga cara yang menyebabkan konfigurasi gagal. Jika job ditempatkan di crontab milik root, WP-CLI berhenti sebelum menjalankan apa pun:

Error: YIKES! It looks like you're running this as root.

Queue tidak pernah berjalan. Jika Anda tidak mengalihkan output, pesan tersebut tidak akan terlihat. Perbaikan yang berbahaya adalah menambahkan --allow-root, karena semua file yang ditulis plugin selama proses tersebut akan menjadi milik root. Web request berikutnya berjalan sebagai www-data, tidak dapat menulis ke direktori tersebut, dan situs mulai menampilkan pesan seperti:

Unable to create directory wp-content/uploads/2026/08. Is its parent directory writable by the server?

Perbaiki kepemilikan file, lalu pindahkan job:

sudo chown -R www-data:www-data /srv/www/example.com/wp-content

Crontab milik root dan crontab milik www-data adalah file yang terpisah. Menghapus baris dari salah satunya tidak memengaruhi yang lain. Periksa keduanya:

sudo crontab -u root -l
sudo crontab -u www-data -l

Mengapa cron melaporkan wp: not found

Ini adalah kegagalan kedua. Cron memberikan PATH yang sangat terbatas untuk job pengguna, yaitu /usr/bin:/bin. WP-CLI terpasang di /usr/local/bin, yang tidak tercantum dalam daftar tersebut. Job dimulai, gagal dalam waktu kurang dari satu detik, dan log berisi satu baris:

/bin/sh: 1: wp: not found

Periksa sendiri environment cron, bukan dengan menebak. Tambahkan baris sementara:

*/5 * * * * env > /tmp/cron-env.txt 2>&1

Baca /tmp/cron-env.txt setelah satu interval, lalu hapus baris tersebut. Nilai PATH= dalam file itu persis sama dengan yang diterima job Anda.

Ada dua cara untuk memperbaikinya. Gunakan path absolut /usr/local/bin/wp, seperti pada langkah 3. Atau tetapkan PATH sekali di bagian atas crontab, sebelum semua baris job:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Masalah yang sama terjadi satu tingkat di bawahnya. Berkas phar wp diawali dengan #!/usr/bin/env php, sehingga shell juga harus dapat menemukan php. Jika PHP berada di luar /usr/bin, seperti pada custom build dan build control panel, Anda akan mendapatkan:

/usr/bin/env: 'php': No such file or directory

Dalam kasus tersebut, panggil interpreter secara eksplisit, misalnya /usr/local/bin/php /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now.

Mengapa interval satu menit mengulangi masalah awal

Ini adalah kegagalan ketiga. * * * * * memang tampak lebih aman daripada lima menit, tetapi pada situs yang sibuk interval ini mengembalikan Anda ke masalah semula. Jika satu eksekusi berlangsung lebih lama daripada interval, eksekusi berikutnya dimulai saat eksekusi pertama masih berjalan. Sepuluh menit kemudian, ada sepuluh proses PHP. Masing-masing menggunakan memorinya sendiri dan koneksi databasenya sendiri.

Periksa penumpukan proses secara langsung:

ps -eo etimes,user,args | grep '[c]ron event run'

etimes adalah usia proses dalam detik. Satu baris berarti kondisi normal. Beberapa baris dengan usia jauh di atas interval Anda berarti eksekusi saling menumpuk. Pada VPS kecil, kondisi ini dapat berakhir dengan error MySQL Too many connections, atau kernel menghentikan PHP untuk membebaskan memori. Anda dapat mengonfirmasinya dengan sudo dmesg -T | grep -i 'killed process'.

WP-CLI menjalankan callback event secara langsung, bukan dengan meminta wp-cron.php. Karena itu, lock 60 detik yang digunakan WordPress untuk mencegah pembuatan proses ganda tidak berlaku di sini. flock -n pada entri langkah 3 sekarang mencegah eksekusi yang tumpang tindih. Eksekusi yang dilewati langsung berhenti tanpa pesan, sesuai rancangan.

Pilih interval berdasarkan jadwal terpendek yang benar-benar Anda perlukan, lalu ukur durasi eksekusi terlebih dahulu:

time sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now

Lima menit adalah nilai default yang wajar: postingan yang dijadwalkan pada 09:00 akan diterbitkan paling lambat 09:05. Lima belas menit cukup untuk situs yang tidak memiliki proses yang sensitif terhadap waktu. Interval satu menit hanya diperlukan oleh toko dan plugin berbasis antrean yang memang membutuhkannya, dan hanya setelah Anda memastikan eksekusi selesai dalam beberapa detik.

Jika tidak dapat menginstal WP-CLI

Beberapa host memblokir alat shell. Permintaan HTTP biasa ke wp-cron.php menjalankan antrean yang sama melalui seluruh stack web:

*/5 * * * * /usr/bin/curl -sS --max-time 120 "https://example.com/wp-cron.php?doing_wp_cron" > /dev/null

Hal-hal yang harus Anda korbankan:

• Eksekusi dibatasi oleh timeout server web dan PHP-FPM, sehingga tugas yang berjalan lama dapat terhenti di tengah proses.
• Sertifikat harus valid, atau curl berhenti dengan SSL certificate problem. Pastikan pembaruan sertifikat tetap berjalan dengan Certbot pada nginx.
• Caching halaman tidak boleh melakukan cache terhadap wp-cron.php, karena permintaan cron akan menerima respons yang tersimpan di cache dan tidak menjalankan apa pun.
• Anda tidak mendapatkan output untuk setiap event. Satu-satunya bukti bahwa sebuah tugas berjalan adalah efek yang dihasilkannya.

-sS membuat curl tidak menampilkan output saat berhasil, tetapi tetap menampilkan error. Perilaku ini sesuai untuk tugas cron.

Hal lain yang perlu dijadwalkan di server

Setelah cron sistem mengambil alih antrean WordPress, tempatkan pekerjaan rutin server lainnya di tempat yang sama agar dapat dipantau. Patch keamanan sistem operasi sebaiknya ditangani oleh unattended upgrades, bukan oleh baris cron yang Anda kelola secara manual. Pembaruan plugin dan tema WordPress memerlukan pertimbangan berbeda: wp plugin update --all di crontab dapat dengan mudah membuat situs produksi gagal pada pukul 3 pagi tanpa ada yang memantau, jadi jalankan pembaruan tersebut secara sengaja, atau setelah melalui tahap staging dan pencadangan.

FAQ

Apakah menonaktifkan WP-Cron menghentikan publikasi postingan terjadwal?

Tidak, selama ada proses lain yang menjalankan antrean. DISABLE_WP_CRON hanya mencegah pemuatan halaman memicu antrean. Event tetap dijadwalkan seperti sebelumnya. Postingan yang ditetapkan untuk 09:00 akan dipublikasikan pada eksekusi cron pertama setelah 09:00, sehingga interval lima menit akan memublikasikannya paling lambat pukul 09:05. Jika Anda menetapkan konstanta tersebut tetapi tidak pernah menambahkan entri cron, postingan akan tetap berada dalam daftar dengan status Missed schedule sampai ada proses yang menjalankan antrean.

Pengguna mana yang harus menjalankan job cron WordPress?

Gunakan pengguna yang memiliki file yang ditulis oleh PHP. Pada instalasi Ubuntu default, pengguna tersebut adalah www-data. Periksa dengan stat -c '%U %G' /srv/www/example.com/wp-content/uploads, lalu bandingkan hasilnya dengan baris user = dalam konfigurasi pool PHP-FPM. Menjalankan job sebagai root membuat WP-CLI berhenti dengan error YIKES. Memaksanya berjalan menggunakan --allow-root akan meninggalkan file milik root di dalam wp-content, sehingga web server tidak dapat menulis ke sana setelahnya.

Seberapa sering system cron harus menjalankan cron WordPress?

Setiap lima menit sesuai untuk sebagian besar situs. Sesuaikan interval dengan jadwal terpendek yang benar-benar Anda andalkan. Pastikan interval tersebut cukup lebih panjang daripada waktu yang diperlukan satu eksekusi. Anda dapat mengukurnya dengan menempatkan time di depan perintah WP-CLI. Pada situs yang sibuk, interval satu menit dapat menyebabkan eksekusi saling menumpuk, kecuali flock mencegahnya.

Mengapa wp cron test gagal setelah saya menonaktifkan WP-Cron?

Karena perintah tersebut menguji pemicuan oleh pengunjung. Perintah itu melaporkan error saat DISABLE_WP_CRON ditetapkan ke true. Hasil tersebut benar pada server yang dikonfigurasi dengan cara ini. Periksa jalur system cron sebagai gantinya. Baca /var/log/wp-cron/example.log, atau jadwalkan event penanda dengan wp cron event schedule, lalu pastikan event tersebut sudah hilang dari wp cron event list setelah eksekusi berikutnya.

Apakah saya memerlukan WP-CLI, atau curl ke wp-cron.php sudah cukup?

curl dapat digunakan. Ini adalah pilihan yang tepat jika Anda tidak dapat memasang WP-CLI. Namun, curl lebih lambat karena memuat WordPress melalui web server. Proses ini juga dibatasi oleh batas waktu request. WP-CLI menjalankan event dalam proses PHP command line tanpa batas waktu web. WP-CLI mencetak satu baris untuk setiap event beserta durasinya. Dengan demikian, log menunjukkan dengan tepat event yang dijalankan dan waktu yang diperlukan.