Nonaktifkan wp-cron dan Gunakan System Cron

Apa itu wp-cron dan alasan system cron menggantikannya

WP-Cron adalah penjadwal tugas bawaan WordPress, dan hanya berjalan ketika seseorang meminta sebuah halaman. Tidak ada proses di dalam WordPress yang aktif sendiri. Pada setiap request yang tidak dilayani dari cache, WordPress membaca daftar job terjadwal. Jika ada job yang waktunya tiba, WordPress mengirim request HTTP kedua kembali ke dirinya sendiri di /wp-cron.php untuk menjalankan job tersebut. Memindahkan job itu ke system cron memberi Anda 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 pekerjaan sebenarnya: sebuah konstanta di wp-config.php dan sebuah entri crontab. Semua hal lain dalam panduan ini membahas informasi yang tidak ditunjukkan oleh kedua baris tersebut. Informasi itu mencakup user yang harus menjalankan job, cara membuktikan bahwa event terjadwal benar-benar dijalankan, serta tiga cara konfigurasi ini dapat gagal tanpa menampilkan apa pun di situs.

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

Biaya cron yang dipicu pengunjung pada situs yang sibuk

Setiap request yang tidak dilayani dari cache harus membayar biaya pemeriksaan ini. WordPress memuat opsi cron, membandingkan timestamp, lalu saat ada pekerjaan yang jatuh tempo, memanggil spawn_cron(). Fungsi tersebut mengirim request loopback non-blocking ke /wp-cron.php. Pengunjung tidak menunggu hasilnya. Namun, worker PHP harus menanganinya. Pada VPS kecil yang menjalankan PHP-FPM dengan pm.max_children = 5, satu scheduled job yang lambat dapat menggunakan seperlima kapasitas PHP selama prosesnya berjalan. Job tersebut kemungkinan besar dipicu pada menit tersibuk karena pada saat itu terjadi paling banyak page load.

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

Hitung frekuensi pemicuan pada server Anda sendiri sebelum memutuskan bahwa hal ini berdampak. 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 per hari merupakan biaya nyata. Jumlah ini sebaiknya diukur pada server Anda sendiri, bukan dibaca dari sebuah artikel. Prinsipnya sama seperti saat Anda melakukan benchmark pada VPS sebelum dan sesudah perubahan lain.

Caching mengubah kondisi ini. Jika page cache menyajikan sebagian besar request sebagai HTML statis, PHP tidak pernah dijalankan untuk request tersebut. Karena itu, pemeriksaan cron juga tidak terjadi. Situs sibuk dengan caching yang kuat mulai berperilaku seperti situs yang sepi di bawah ini.

Pengunjung mana yang memicu cron pada situs yang sepi

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

Gejalanya selalu sama. Pos yang dijadwalkan untuk pukul 09:00 tetap berada dalam daftar pos dengan status Missed schedule sampai seseorang memuat halaman. Plugin pencadangan melewati jadwal malam. Pemeriksaan pembaruan terlambat, sehingga dashboard tidak menampilkan pembaruan apa pun saat rilis keamanan sudah tersedia. Email pesanan, pemberitahuan perpanjangan, dan peringatan kedaluwarsa terkirim terlambat.

Tidak ada error yang tercatat. 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 di atas baris yang berbunyi /* That's all, stop editing! Happy publishing. */, karena baris tepat di bawah komentar tersebut memerlukan wp-settings.php, dan wp-settings.php adalah tempat WordPress memasang pemeriksaan cron pada init. Konstanta yang didefinisikan setelah require tersebut akan ditetapkan terlalu terlambat untuk mengubah apa pun, sehingga file terlihat benar sementara 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 mencegah pemuatan halaman 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, dan biasanya hal ini tidak berbahaya karena file tersebut hanya menjalankan tugas yang sudah jatuh tempo. Pemblokiran URL itu pada konfigurasi web server bersifat opsional. Jika Anda memblokirnya, fallback curl di dekat akhir panduan ini juga tidak akan berfungsi.

Langkah 2: memasang 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 web server.

php -v
sudo apt install -y php-cli

Pasang WP-CLI dari build phar, sesuai rekomendasi 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 mencetak path biner PHP, versi PHP, dan versi WP-CLI. Jika ketiganya tercetak, 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 melampaui persyaratan tersebut. Perbarui nanti dengan sudo wp cli update.

Jalankan WP-CLI sebagai pengguna situs, bukan sebagai root:

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

Sebagai root, WP-CLI menolak untuk berjalan:

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

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

Perhatikan juga bahwa sudo -u www-data -i tidak berfungsi karena shell login akun tersebut adalah /usr/sbin/nologin dan Anda mendapatkan This account is currently not available.. Meneruskan perintah langsung ke sudo -u melewati shell login, sehingga perintah dapat 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 ditempatkan setelah require.

Langkah 3: tambahkan entri cron sebagai user yang tepat

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

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 memberi site tersebut PHP-FPM pool sendiri dengan user sendiri, yang biasanya menjadi hasil konfigurasi per-site pada stack LAMP di Ubuntu 24.04, gunakan user tersebut untuk semua langkah berikut.

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

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

Dalam praktiknya, redirect tersebut wajib digunakan. Cron mengirim output job ke user-nya melalui email, sedangkan sebagian besar image VPS tidak memasang mail transfer agent. Cron kemudian mencatat (CRON) info (No MTA installed, discarding output) dan membuang output tersebut. File menyimpan bukti eksekusi.

Periksa file yang disimpan:

sudo crontab -u www-data -l

Untuk beberapa site, gunakan satu baris untuk setiap site dengan menit yang dibuat berbeda agar semuanya tidak berjalan secara 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 membesar 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 menjalankan command tersebut? Cron menulis log ke journal melalui unit-nya sendiri:

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

Entri yang normal terlihat seperti ini, setelah timestamp dan hostname di bagian awal dihapus:

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 menjalankan command Anda sebagai www-data. Baris itu tidak menunjukkan apakah command 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. Sebagian besar eksekusi tidak memiliki event yang jatuh tempo dan hanya menulis sedikit informasi. Karena itu, baca file setelah eksekusi yang Anda ketahui memiliki pekerjaan yang menunggu.

Ketiga, buktikan seluruh proses dari awal hingga akhir. Jadwalkan event penanda, lalu lihat event tersebut menghilang:

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 command untuk menampilkan daftar. Hook tersebut sudah tidak ada karena event satu kali dihapus dari antrean setelah 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 dijalankan. Dua pemeriksaan pertama akan menunjukkan apakah masalahnya ada pada cron atau WP-CLI.

Jangan gunakan wp cron test untuk pemeriksaan ini. Command tersebut memeriksa apakah pemanggilan proses oleh visitor dapat berjalan, dan menghasilkan error jika DISABLE_WP_CRON benar. Pada server yang dikonfigurasi dengan benar, error tersebut adalah output yang diharapkan, bukan masalah.

Alternatif timer systemd

Jika pekerjaan terjadwal lain di server sudah berjalan sebagai service dan timer systemd, tempatkan WordPress di sana juga. Setiap eksekusi akan tercatat di 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 menjalankan pekerjaan yang terlewat saat mesin mati, sesuatu yang tidak dapat dilakukan oleh entri crontab.

Pilih crontab atau timer. Menjalankan keduanya untuk situs yang sama berarti antrean diproses dua kali, dan eksekusi ganda 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 dimasukkan ke crontab milik root, WP-CLI berhenti sebelum melakukan apa pun:

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

Queue tidak pernah dijalankan. Jika output tidak dialihkan, pesan tersebut tidak akan terlihat. Solusi yang berbahaya adalah menambahkan --allow-root, karena semua file yang ditulis plugin selama eksekusi tersebut akan menjadi milik root. Permintaan web 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 file 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 singkat untuk job pengguna, /usr/bin:/bin. WP-CLI terpasang di /usr/local/bin, yang tidak tercantum dalam PATH 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 sama persis dengan yang diterima job Anda.

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

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

Masalah yang sama juga terjadi satu tingkat di bawahnya. 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 dari 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. * * * * * tampak lebih aman daripada lima menit, tetapi pada situs yang sibuk interval ini mengembalikan Anda ke kondisi awal. Jika satu eksekusi memerlukan waktu lebih lama daripada interval, eksekusi berikutnya dimulai saat eksekusi pertama masih berjalan. Sepuluh menit kemudian, terdapat sepuluh proses PHP, yang masing-masing menggunakan memori dan koneksi database 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 sebagai error Too many connections dari MySQL 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, kunci 60 detik yang digunakan WordPress untuk mencegah pembuatan proses duplikat tidak berlaku di sini. flock -n pada entri langkah 3 yang mencegah eksekusi saling tumpang tindih. Eksekusi yang dilewati langsung berhenti tanpa pesan, sesuai desain. Tumpang tindih harus Anda atasi di crontab, bukan mengandalkan kernel host: bahkan penempatan task yang mempertimbangkan cache dan ditambahkan di Linux kernel 7.2 hanya menentukan core tempat proses dijalankan, bukan jumlah proses yang Anda mulai.

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: post yang dijadwalkan pada 09:00 akan diterbitkan paling lambat pada 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 queue yang memang membutuhkannya, dan hanya setelah Anda memastikan bahwa satu eksekusi selesai dalam beberapa detik.

Jika Anda tidak dapat memasang WP-CLI

Beberapa host memblokir alat shell. Permintaan HTTP biasa ke wp-cron.php menjalankan antrean yang sama, tetapi melalui seluruh tumpukan 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 terima:

• Eksekusi dibatasi oleh batas waktu permintaan server web dan PHP-FPM, sehingga pekerjaan yang lama dapat terhenti di tengah proses.
• Sertifikat harus valid atau curl berhenti dengan SSL certificate problem. Karena itu, pastikan pembaruan tetap berjalan dengan Certbot pada nginx.
• Caching halaman tidak boleh menyimpan wp-cron.php dalam cache. Jika tidak, permintaan cron menerima respons yang tersimpan dalam cache dan tidak ada pekerjaan yang dijalankan.
• Anda tidak mendapatkan output untuk setiap peristiwa. Satu-satunya bukti bahwa suatu pekerjaan berjalan adalah dampak yang dihasilkannya.

-sS membuat curl tetap tenang saat berhasil, tetapi tetap mencetak error. Inilah perilaku yang diperlukan dalam cron job.

Apa lagi yang perlu dijadwalkan di server

Setelah cron sistem menangani antrean WordPress, tempatkan pekerjaan rutin server lainnya di lokasi yang sama agar semuanya mudah 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 yang berbeda: wp plugin update --all di crontab dapat dengan mudah merusak situs yang sedang aktif pada pukul 3 pagi tanpa ada yang memantaunya. Karena itu, jalankan pembaruan tersebut secara sengaja, atau lakukan melalui tahap staging dan pencadangan.

FAQ

Apakah menonaktifkan WP-Cron menghentikan publikasi tulisan terjadwal?

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

Pengguna mana yang harus menjalankan cron job WordPress?

Gunakan pengguna yang memiliki file yang ditulis oleh PHP, yaitu www-data pada instalasi Ubuntu default. Periksa dengan stat -c '%U %G' /srv/www/example.com/wp-content/uploads, lalu bandingkan hasilnya dengan baris user = dalam konfigurasi pool PHP-FPM Anda. Menjalankan job sebagai root membuat WP-CLI berhenti dengan error YIKES. Memaksanya 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 sudah sesuai untuk sebagian besar situs. Sesuaikan interval dengan jadwal terpendek yang benar-benar Anda andalkan, dan pastikan interval tersebut lebih panjang secara memadai daripada durasi satu eksekusi. Anda dapat mengukurnya dengan menambahkan time di depan perintah WP-CLI. Pada situs yang sibuk, interval satu menit dapat menumpuk beberapa eksekusi, kecuali flock digunakan untuk mencegahnya.

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

Karena perintah tersebut menguji pemicuan proses oleh pengunjung, dan melaporkan error ketika DISABLE_WP_CRON ditetapkan ke true. Itu adalah hasil yang benar pada server yang dikonfigurasi seperti 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, dan itu merupakan pilihan yang tepat jika Anda tidak dapat memasang WP-CLI. Prosesnya lebih lambat karena WordPress dimuat melalui web server, serta dibatasi oleh batas waktu request. WP-CLI menjalankan event dalam proses PHP command line tanpa batas waktu web, lalu mencetak satu baris untuk setiap event beserta durasinya. Dengan demikian, log menunjukkan dengan tepat proses yang berjalan dan durasinya.