Fix a missing LogSpot report

1. Confirm LogSpot is enabled on the site’s application server.
2. Read that server’s final action output and check systemctl status cpfcli-logspot.service and journalctl -u cpfcli-logspot.service as an administrator.
3. Generate a normal site request, then check whether collection and report files appear.
4. Inspect the site’s document root. Generated viewers live in the site’s public_html/traffic-reports and, when present, httpdocs/traffic-reports.
5. For a custom document root, follow the link example below with the site administrator. Confirm the destination and protect authentication before creating it.

Check collection on the site's application server before changing report paths. Do not remove stored data to repair a URL. Select the image to enlarge it; use your browser's Back command to return.

Preserve existing paths and report access

Do not overwrite an existing traffic-reports path or copy an example link without checking where it resolves. Do not delete stored reports to repair a URL. Keep viewer credentials private.

Use the reviewed Restart LogSpot Module control after resolving the reported problem. A zero file-size cap truncates logs; it does not mean unlimited. See LogSpot controls.

Make the viewer accessible from a custom document root

If LogSpot has generated its viewer but /traffic-reports/ still returns 404, check the site’s configured document root in Enhance. A custom root can put the generated viewer outside the directory served by the website.

For example, the website’s user container may contain:

/public_html/traffic-reports/    Generated LogSpot viewer
/public_html/custom-root/       Website's configured document root

The following example applies only to that layout. Use the website’s system user on its application server, and substitute the actual custom-root directory.

1. Open the custom document root and check that the existing viewer files are present in its sibling directory:

   cd /public_html/custom-root
   ls -l ../traffic-reports/index.php ../traffic-reports/logview.php

   If either file is missing, return to the collection and service checks above. A link cannot generate a missing report.

2. Check whether the custom root already contains a traffic-reports path:

   ls -ld traffic-reports

   If it exists, inspect it with the site administrator. Do not replace it. If it is absent, create a link to the generated viewer:

   ln -sT -- ../traffic-reports traffic-reports

   This refuses to replace any existing path, including a dangling symlink. The relative target is correct only for the sibling layout shown above.

3. Verify where the new link resolves:

   readlink -f traffic-reports

   Expect the existing /public_html/traffic-reports directory in this example. Then open https://example.com/traffic-reports/, replacing the domain with yours, and verify the intended login and report access. Use generated credentials, or the deliberately configured WHMCS auto-login flow.

If the URL returns 403 or downloads PHP instead of running the viewer, ask the site administrator to check PHP handling, permissions and the web server’s symlink policy. Do not disable authentication or copy private logs into the public document root to repair access.

Undo the example link

From the same custom root, run readlink traffic-reports and confirm it is still the ../traffic-reports link you created. Then remove only that link:

test -L traffic-reports && unlink traffic-reports

This leaves the generated viewer and stored reports in place. Do not delete the real traffic-reports directory as a rollback.