Masalah seperti ini tidak selalu berarti ada kerusakan pada kode Laravel. Penyebabnya bisa berasal dari exception aplikasi, konfigurasi .env, koneksi database, permission direktori, versi PHP, hingga service PHP-FPM atau web server yang bermasalah.

Saat menangani error seperti ini, saya akan memulai dari bukti yang paling mudah diperiksa: log aplikasi dan log server. Dengan begitu, kamu tidak perlu langsung mengubah banyak konfigurasi yang sebenarnya belum tentu berkaitan dengan masalah.

Panduan ini menggunakan contoh lingkungan VPS Linux dengan Laravel, Nginx, dan PHP-FPM. Jika kamu memakai Apache, CyberPanel, atau panel hosting lain, beberapa lokasi log dan nama service mungkin berbeda.

Kenapa Laravel Mengalami Error 500 di VPS?

Laravel 500 Internal Server Error terjadi ketika aplikasi atau komponen server gagal memproses permintaan HTTP. Penyebab pastinya perlu diketahui dari log, bukan hanya dari halaman error di browser.

Pemeriksaan awal yang paling berguna adalah:

1. Buka storage/logs/laravel.log untuk mencari exception Laravel.

2. Periksa log Nginx atau Apache serta PHP-FPM jika log Laravel tidak menjelaskan masalah.

3. Pastikan konfigurasi .env, koneksi database, dan permission direktori sudah benar.

4. Setelah memperbaiki penyebabnya, jalankan pemeriksaan konfigurasi dan uji kembali website.

Jangan langsung menjalankan chmod -R 777, menghapus cache secara menyeluruh, atau me-restart semua service. Tindakan tersebut belum tentu menyelesaikan akar masalah dan dapat menimbulkan risiko tambahan.

Gejala dan Penyebab Laravel 500 Internal Server Error

HTTP 500 merupakan respons umum yang menunjukkan server mengalami kegagalan saat memproses permintaan. Informasi yang terlihat di browser biasanya tidak cukup untuk menentukan sumber masalah.

Berikut beberapa kemungkinan penyebab yang perlu dibedakan.

Tabel tersebut merupakan panduan diagnosis, bukan daftar penyebab yang sudah terkonfirmasi pada server kamu. Satu gejala dapat memiliki beberapa kemungkinan penyebab.

Periksa Log Laravel Sebelum Mengubah Konfigurasi

Langkah pertama adalah menemukan pesan error yang benar-benar dicatat aplikasi.

Masuk ke VPS menggunakan SSH, kemudian pindah ke direktori proyek Laravel. Misalnya, jika proyek berada di /var/www/myapp:

cd /var/www/myapp

Pastikan direktori tersebut memang berisi aplikasi Laravel. Kamu biasanya akan menemukan file artisan, composer.json, serta direktori app, bootstrap, config, routes, dan storage.

Periksa log terbaru:

ls -lah storage/logs/

Pada instalasi Laravel yang menggunakan log file, nama file dapat berupa laravel.log atau file log harian, tergantung konfigurasi logging.

Jika menggunakan laravel.log, lihat beberapa baris terakhir:

tail -n 100 storage/logs/laravel.log

Jika file log harian digunakan, sesuaikan nama file dengan hasil perintah ls.

Perintah tail hanya membaca bagian akhir file. Cari pesan seperti:

• SQLSTATE: biasanya berkaitan dengan database atau query SQL.

• Class not found atau Class ... does not exist: bisa menunjukkan dependensi, autoload, atau referensi kelas yang bermasalah.

• Permission denied: mengarah pada akses file atau direktori.

• No application encryption key has been specified: Laravel tidak menemukan konfigurasi APP_KEY yang diperlukan.

• Maximum execution time exceeded: proses PHP melewati batas waktu eksekusi.

• Allowed memory size exhausted: proses kehabisan alokasi memori PHP.

Perhatikan timestamp error dan URL yang sedang diakses. Pesan yang paling baru dan sesuai dengan waktu kejadian biasanya lebih relevan daripada error lama di dalam file log.

Jika log Laravel sudah menunjukkan exception yang jelas, tangani penyebab tersebut terlebih dahulu. Tidak perlu langsung mengubah Nginx atau permission jika belum ada indikasi bahwa keduanya bermasalah.

Bagaimana jika laravel.log tidak ditemukan?

Tidak adanya file log belum membuktikan bahwa Laravel tidak menghasilkan error. Bisa jadi logging diarahkan ke kanal lain, direktori log tidak dapat ditulis, atau permintaan gagal sebelum aplikasi mencatat exception.

Periksa konfigurasi logging pada config/logging.php dan nilai terkait di .env. Hindari membagikan seluruh file .env ketika meminta bantuan karena file tersebut dapat berisi kata sandi dan kredensial sensitif.

Periksa Log Nginx, Apache, dan PHP-FPM

Jika log Laravel kosong atau tidak menunjukkan penyebab yang jelas, pemeriksaan berikutnya adalah lapisan server yang menjalankan aplikasi.

Jika VPS menggunakan Nginx

Pada Ubuntu atau Debian dengan instalasi Nginx standar, log error biasanya berada di /var/log/nginx/error.log.

sudo tail -n 100 /var/log/nginx/error.log

Perhatikan pesan yang muncul pada waktu kamu mengakses website. Beberapa contoh petunjuk yang mungkin ditemukan:

• connect() failed atau Connection refused: Nginx mungkin tidak dapat terhubung ke upstream yang dituju, misalnya socket PHP-FPM.

• Permission denied: bisa berkaitan dengan akses file, direktori, atau socket.

• upstream timed out: proses di belakang Nginx tidak memberikan respons dalam batas waktu yang ditentukan.

• Primary script unknown: dapat mengarah pada konfigurasi FastCGI atau lokasi file PHP yang tidak sesuai.

Pesan-pesan tersebut adalah contoh pola diagnosis, bukan output yang pasti muncul pada VPS kamu. Cocokkan dengan konfigurasi dan timestamp log. Dokumentasi resmi Nginx menjelaskan bahwa lokasi log bergantung pada konfigurasi instalasi dan directive error_log.

Jika menggunakan Apache

Pada banyak instalasi Ubuntu atau Debian, log error Apache tersedia di lokasi berikut:

sudo tail -n 100 /var/log/apache2/error.log

Untuk distribusi atau panel hosting lain, lokasi log dapat berbeda. Jika file tidak ditemukan, periksa konfigurasi virtual host atau dokumentasi panel yang digunakan.

Periksa status PHP-FPM

PHP-FPM adalah service yang menjalankan proses PHP untuk web server seperti Nginx. Nama servicenya biasanya menyertakan versi PHP, misalnya php8.2-fpm atau php8.3-fpm, tetapi versi sebenarnya harus disesuaikan dengan VPS.

Cari service yang tersedia:

systemctl list-units --type=service --all | grep -E 'php.*fpm'

Setelah mengetahui nama service, periksa statusnya. Contohnya:

sudo systemctl status php8.3-fpm --no-pager

Ganti php8.3-fpm dengan nama service yang benar. Jika statusnya failed, periksa log service:

sudo journalctl -u php8.3-fpm -n 100 --no-pager

Jika PHP-FPM berjalan normal, itu belum membuktikan seluruh proses PHP sehat. Periksa juga log aplikasi dan konfigurasi pool FPM apabila ditemukan error yang mengarah ke sana.

Pastikan Versi PHP dan Dependensi Laravel Sesuai

Error 500 yang muncul setelah deployment atau pembaruan server dapat berkaitan dengan versi PHP yang tidak sesuai dengan kebutuhan proyek.

Periksa versi PHP CLI:

php -v

Kemudian periksa dependensi Laravel:

composer check-platform-reqs

Perintah kedua memeriksa apakah platform PHP dan ekstensi yang dibutuhkan oleh dependensi Composer tersedia pada lingkungan tempat perintah dijalankan.

Perlu diperhatikan: PHP CLI dan PHP-FPM bisa menggunakan versi atau konfigurasi yang berbeda. Jadi, hasil pemeriksaan CLI yang normal tidak otomatis menjamin runtime website menggunakan konfigurasi yang sama.

Periksa pula versi Laravel jika Artisan dapat dijalankan:

php artisan --version

Jika muncul error saat menjalankan perintah tersebut, catat pesannya. Error pada tahap bootstrap bisa membantu mengarahkan diagnosis ke konfigurasi aplikasi, autoload, atau dependensi.

Jika dependensi Composer bermasalah

Pastikan composer.json dan composer.lock sesuai dengan versi aplikasi yang sedang di-deploy. Pada server produksi, instal dependensi dari lock file yang sudah disiapkan dan diuji, bukan memperbarui seluruh dependensi secara spontan.

Contoh perintah untuk deployment produksi:

composer install --no-dev --prefer-dist --optimize-autoloader

Jalankan dari direktori proyek setelah memastikan versi PHP dan ekstensi yang diperlukan tersedia. Perintah ini dapat mengubah direktori vendor, sehingga sebaiknya dilakukan sebagai bagian dari proses deployment yang memiliki backup atau mekanisme rollback.

Jika masalah dimulai setelah pembaruan dependensi, bandingkan perubahan pada composer.lock dan kode yang di-deploy sebelum mencoba memperbarui paket lain.

Periksa Konfigurasi .env dan Koneksi Database

File .env menyimpan pengaturan lingkungan aplikasi, termasuk nama database, kredensial, dan konfigurasi layanan. Kesalahan pada nilai tertentu dapat membuat Laravel gagal memproses permintaan.

Buka file .env menggunakan editor di server:

nano .env

Periksa nilai yang relevan, misalnya:

APP_ENV=productionAPP_DEBUG=falseDB_CONNECTION=mysqlDB_HOST=127.0.0.1DB_PORT=3306DB_DATABASE=nama_databaseDB_USERNAME=nama_userDB_PASSWORD=kata_sandi_database

Nilai di atas hanya contoh format. Sesuaikan dengan lingkungan sebenarnya. Pada beberapa konfigurasi, DB_HOST dapat menggunakan alamat lain atau socket lokal.

Jangan menyalin contoh tersebut begitu saja ke server. Pastikan database, username, password, dan port benar, serta database dapat diakses dari host aplikasi.

Cara mengenali masalah database

Jika log Laravel memuat SQLSTATE, baca kode dan pesan lengkapnya. Sebagai contoh, masalah koneksi, autentikasi, dan tabel yang tidak ditemukan memerlukan tindakan berbeda.

• Connection refused atau gagal terhubung: periksa alamat database, port, status service, dan aturan jaringan.

• Access denied: periksa username, password, hak akses user database, dan host asal koneksi.

• Table not found: periksa skema database dan apakah migrasi yang diperlukan sudah diterapkan.

• Unknown database: periksa nama database pada konfigurasi aplikasi.

Jika database berjalan di server yang sama dan menggunakan MySQL atau MariaDB, kamu dapat memeriksa status service dengan nama yang sesuai:

sudo systemctl status mysql --no-pager

Pada distribusi tertentu, nama servicenya adalah mariadb. Jangan menganggap database mati hanya karena perintah dengan nama service yang berbeda gagal.

Jika .env sudah benar tetapi Laravel masih memakai konfigurasi lama

Laravel dapat menggunakan cache konfigurasi. Setelah memverifikasi nilai .env, pertimbangkan untuk membersihkan cache konfigurasi:

php artisan config:clear

Perintah ini menghapus cache konfigurasi Laravel. Lakukan dari direktori proyek dan pastikan kamu menjalankan Artisan dengan PHP yang sesuai untuk aplikasi.

Setelah itu, uji kembali website. Jika deployment produksi memang menggunakan konfigurasi cache, jalankan proses pembuatan cache sesuai prosedur deployment:

php artisan config:cache

Jangan menjalankan kedua perintah tersebut secara membabi buta pada aplikasi yang sedang melayani trafik. Pastikan konfigurasi lingkungan sudah benar dan ikuti prosedur deployment agar aplikasi tidak berjalan dengan konfigurasi yang belum siap. Laravel juga memperingatkan bahwa pemanggilan env() di luar file konfigurasi dapat menimbulkan masalah setelah konfigurasi di-cache.

Periksa Permission Folder storage dan bootstrap/cache

Laravel perlu menulis file ke direktori tertentu, terutama storage dan bootstrap/cache. Jika proses PHP tidak memiliki izin yang sesuai, aplikasi dapat gagal menulis log, cache, atau file hasil kompilasi view.

Periksa ownership dan permission:

ls -ld storage bootstrap/cache

Lihat juga isi direktori yang relevan:

ls -lah storage/logsls -lah bootstrap/cache

Cari petunjuk seperti direktori yang dimiliki user yang tidak sesuai atau file yang tidak dapat ditulis oleh proses PHP.

Tentukan user yang menjalankan PHP

Jangan langsung menganggap PHP berjalan sebagai www-data. Nama user bergantung pada konfigurasi VPS, PHP-FPM pool, serta panel hosting.

Pada server dengan systemd, periksa konfigurasi pool PHP-FPM yang digunakan oleh website dan cari nilai user serta group. Konfigurasi tersebut biasanya berada di direktori seperti /etc/php/<versi>/fpm/pool.d/, tetapi jalurnya dapat berbeda.

Setelah mengetahui user dan group yang benar, sesuaikan ownership serta izin direktori agar proses PHP dapat menulis di lokasi yang diperlukan. Hindari memberikan hak tulis kepada semua user.

Jangan menggunakan chmod -R 777 sebagai solusi. Perintah itu memberikan izin yang terlalu luas dan dapat meningkatkan risiko keamanan, terutama jika diterapkan ke seluruh proyek.

Untuk referensi, dokumentasi deployment Laravel menyebutkan bahwa proses web harus memiliki akses tulis ke storage dan bootstrap/cache.

Periksa APP_KEY dan Cache Aplikasi

Jika log menyatakan bahwa application encryption key tidak tersedia, periksa nilai APP_KEY pada .env.

APP_KEY=base64:nilai_kunci_yang_sudah_ada

Baris tersebut hanya contoh format, bukan nilai yang dapat digunakan secara langsung.

Jika aplikasi yang sudah berjalan kehilangan APP_KEY, jangan langsung menjalankan php artisan key:generate di produksi. Mengganti kunci dapat membuat data yang sebelumnya dienkripsi dengan kunci lama tidak lagi dapat dibaca, termasuk data sesi atau nilai terenkripsi tertentu.

Tindakan yang lebih aman adalah memulihkan kunci asli dari backup atau secret manager yang digunakan dalam deployment. Jika aplikasi benar-benar baru dan belum menyimpan data terenkripsi, pembuatan kunci baru bisa dilakukan sebagai bagian dari proses instalasi yang benar.

Jika log mengarah pada cache konfigurasi, route, atau view yang tidak sesuai setelah deployment, kamu dapat mempertimbangkan pembersihan cache yang relevan setelah memastikan penyebabnya.

Misalnya:

php artisan view:clear

Perintah ini menghapus cache view hasil kompilasi. Gunakan hanya jika indikasi masalah berkaitan dengan view atau hasil kompilasi yang tidak sesuai. Tidak semua HTTP 500 memerlukan pembersihan cache.

Periksa Ruang Disk dan Memori VPS

Kapasitas disk yang habis dapat membuat aplikasi gagal menulis log, file sementara, atau cache. Tekanan memori juga dapat menyebabkan proses PHP terhenti atau tidak mampu menyelesaikan permintaan.

Periksa ruang disk:

df -h

Perhatikan partisi yang mencapai kapasitas penuh, terutama partisi yang menampung proyek, log, atau direktori sementara.

Periksa penggunaan memori:

free -h

Untuk melihat kondisi proses saat ini, kamu dapat menjalankan:

top

Jika kapasitas disk hampir penuh, cari sumber penggunaan ruang sebelum menghapus file. Jangan menghapus log, file upload, atau data aplikasi secara sembarangan. Jika memori tidak mencukupi, periksa proses yang mengonsumsi sumber daya dan pola trafik sebelum memutuskan menambah RAM atau mengubah konfigurasi PHP.

Kondisi sumber daya yang buruk tidak selalu menghasilkan HTTP 500 secara langsung, tetapi tetap perlu diperiksa jika error muncul bersamaan dengan perlambatan atau kegagalan proses.

Pastikan Document Root Mengarah ke Folder public

Konfigurasi web server yang tidak sesuai juga dapat menyebabkan aplikasi Laravel gagal berjalan dengan benar.

Untuk Nginx, document root website Laravel umumnya diarahkan ke direktori public milik proyek, bukan ke root proyek secara keseluruhan.

Contoh konfigurasi dasar:

server {listen 80;server_name example.com www.example.com;root /var/www/myapp/public;index index.php index.html;location / {try_files $uri $uri/ /index.php?$query_string;}location ~ \.php$ {include fastcgi_params;fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;fastcgi_pass unix:/run/php/php8.3-fpm.sock;}}

Konfigurasi ini hanya contoh dasar. Socket PHP-FPM, jalur fastcgi_params, pengaturan HTTPS, dan aturan keamanan harus disesuaikan dengan lingkungan kamu. Jangan mengganti seluruh konfigurasi virtual host produksi dengan contoh ini tanpa membandingkan konfigurasi yang sudah ada.

Periksa apakah root menunjuk ke folder public yang benar dan apakah socket yang disebutkan memang tersedia. Jika Nginx tidak dapat menghubungi socket PHP-FPM, log biasanya memberikan petunjuk yang lebih spesifik.

Uji konfigurasi sebelum reload

Jika kamu mengubah konfigurasi Nginx, jalankan:

sudo nginx -t

Jika hasilnya menunjukkan konfigurasi valid, barulah pertimbangkan untuk menerapkan perubahan:

sudo systemctl reload nginx

reload meminta Nginx memuat ulang konfigurasi tanpa menghentikan service secara penuh. Meski begitu, lakukan perubahan secara terencana, terutama pada server produksi. Jika pengujian konfigurasi gagal, jangan lanjutkan reload.

Pastikan APP_DEBUG Tidak Aktif di Produksi

Saat Laravel mengalami error, sebagian orang mencoba mengaktifkan debug agar pesan detail muncul di browser. Cara ini dapat membantu diagnosis pada lingkungan pengembangan, tetapi berbahaya jika diterapkan pada website publik.

Untuk produksi, pastikan konfigurasi berikut digunakan:

APP_ENV=productionAPP_DEBUG=false

Laravel secara resmi menyarankan APP_DEBUG=false di lingkungan produksi karena mode debug dapat mengekspos informasi sensitif kepada pengunjung.

Jika kamu memerlukan detail error, gunakan log yang hanya dapat diakses oleh pihak berwenang. Jangan membiarkan halaman publik menampilkan stack trace, jalur internal server, kredensial, atau informasi konfigurasi.

Setelah memperbaiki konfigurasi, pastikan aplikasi menggunakan nilai yang benar. Jika konfigurasi di-cache, perbarui cache melalui proses deployment yang sesuai.

Cara Memilih Solusi Berdasarkan Hasil Diagnosis

Supaya kamu tidak mengubah banyak hal sekaligus, gunakan hasil pemeriksaan sebagai dasar tindakan.

Verifikasi Setelah Perbaikan

Setelah melakukan perubahan, jangan hanya mengandalkan halaman yang tampak normal sekali. Periksa kembali respons HTTP, log, dan service yang relevan.

1. Uji respons website

Dari VPS atau komputer lain yang dapat mengakses domain, jalankan:

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/

Ganti example.com dengan domain website kamu.

Perintah tersebut menampilkan kode status HTTP dari permintaan. Hasil 200 menunjukkan permintaan itu berhasil memperoleh respons HTTP 200, tetapi belum membuktikan semua fitur aplikasi berjalan normal.

Jika hasilnya masih 500, lanjutkan dengan memeriksa log terbaru. Jika hasilnya 301 atau 302, periksa alur redirect. Jika hasilnya 502 atau 504, fokuskan diagnosis pada koneksi ke upstream, PHP-FPM, atau timeout.

2. Periksa log setelah pengujian

Segera setelah mengakses halaman yang bermasalah, periksa kembali log Laravel:

tail -n 50 storage/logs/laravel.log

Jika menggunakan log harian, gunakan file yang sesuai. Periksa juga log Nginx, Apache, atau PHP-FPM jika ada indikasi kegagalan pada lapisan server.

3. Periksa service yang terkait

Jika kamu mengubah konfigurasi service, periksa statusnya:

sudo systemctl status nginx --no-pager

Untuk PHP-FPM, sesuaikan nama servicenya dengan versi yang benar:

sudo systemctl status php8.3-fpm --no-pager

Status active (running) merupakan indikator bahwa service berjalan, bukan jaminan bahwa konfigurasi aplikasi sudah benar. Tetap uji endpoint dan baca log setelah perubahan.

4. Uji fitur yang terdampak

Selain halaman utama, coba endpoint yang sebelumnya menghasilkan 500. Jika masalah hanya terjadi pada dashboard, API, atau proses tertentu, pengujian perlu mencakup fungsi tersebut.

Panduan ini tidak didasarkan pada log atau hasil pengujian dari VPS tertentu, sehingga keberhasilan perbaikan belum dapat dipastikan sebelum pemeriksaan dilakukan pada lingkungan kamu sendiri.

Cara Mencegah Laravel 500 Error Terulang

Beberapa kebiasaan berikut dapat mengurangi risiko error yang sulit dilacak:

1. Simpan log yang memadai. Pastikan error aplikasi dan web server dapat diperiksa oleh administrator, dengan retensi yang sesuai agar disk tidak cepat penuh.

2. Gunakan proses deployment yang konsisten. Uji perubahan kode, dependensi, dan migrasi sebelum diterapkan ke produksi.

3. Validasi konfigurasi sebelum reload. Untuk Nginx, gunakan nginx -t sebelum menerapkan perubahan konfigurasi.

4. Kelola .env dengan aman. Jangan memasukkan kredensial ke repositori publik dan jangan mengganti APP_KEY aplikasi yang sudah berjalan tanpa memahami dampaknya.

5. Pantau kapasitas server. Periksa disk, memori, dan beban proses agar keterbatasan sumber daya dapat diketahui lebih awal.

6. Sesuaikan permission secara terukur. Pastikan proses PHP dapat menulis ke direktori yang dibutuhkan, tanpa membuka akses tulis ke seluruh proyek.

7. Jangan menampilkan detail error kepada pengunjung. Pertahankan APP_DEBUG=false pada produksi dan gunakan log privat untuk diagnosis.

FAQ

1. Kenapa Laravel menampilkan HTTP 500 setelah dipindahkan ke VPS?

Penyebabnya bisa berupa konfigurasi .env yang tidak sesuai, dependensi Composer yang belum terpasang, permission direktori, versi PHP yang berbeda, atau koneksi database yang gagal. Periksa storage/logs dan log server untuk menemukan petunjuk spesifik.

2. Apakah php artisan optimize:clear bisa memperbaiki error 500?

Bisa membantu jika masalah memang berasal dari cache konfigurasi atau cache Laravel yang tidak sesuai. Namun, perintah tersebut tidak memperbaiki bug PHP, kredensial database yang salah, atau permission yang bermasalah. Cari penyebabnya terlebih dahulu sebelum membersihkan cache.

3. Apakah permission Laravel harus menggunakan 777?

Tidak. Permission 777 memberikan hak baca, tulis, dan eksekusi kepada semua user untuk file atau direktori yang dikenai perintah. Pendekatan yang lebih aman adalah mengatur ownership dan permission berdasarkan user yang menjalankan PHP-FPM serta kebutuhan direktori Laravel.

4. Bolehkah mengaktifkan APP_DEBUG=true untuk melihat penyebab error?

Gunakan mode debug hanya pada lingkungan pengembangan yang aman. Di produksi, pertahankan APP_DEBUG=false dan periksa log aplikasi atau server agar informasi sensitif tidak terlihat oleh pengunjung.

5. Bagaimana jika log Laravel kosong tetapi website masih menampilkan error 500?

Periksa konfigurasi logging, permission direktori log, serta log Nginx atau Apache dan PHP-FPM. Kegagalan mungkin terjadi sebelum Laravel sempat menulis log, atau log aplikasi diarahkan ke kanal lain. Periksa timestamp dan URL yang diuji agar pesan yang ditemukan sesuai dengan kejadian.

Penutup

Untuk mengatasi Laravel 500 Internal Server Error di VPS, mulai dari log Laravel, kemudian lanjutkan ke log web server, PHP-FPM, konfigurasi aplikasi, database, dan permission sesuai petunjuk yang ditemukan. Hindari mengubah banyak hal sekaligus karena tindakan tersebut dapat menyulitkan penelusuran akar masalah.

Jika error tetap terjadi, kumpulkan pesan exception yang relevan, waktu kejadian, versi PHP, jenis web server, dan perubahan terakhir sebelum masalah muncul. Samarkan kredensial serta informasi sensitif sebelum membagikan log atau konfigurasi. Dengan informasi tersebut, diagnosis dapat dilakukan lebih terarah tanpa menebak penyebabnya.