Logs that help explain what happened

Logs are useful only when users can find the source that answers their question. SHM groups account-visible logs by purpose:

• web access and web errors;
• ModSecurity and HTTP Guard;
• FTP, account login and mail authentication.

Domain-scoped logs share the full domain list owned by the account, including the main domain, addons, parked domains, and subdomains where applicable.

This removes the need to know whether a particular server stores a web error under Apache, Nginx, a proxy path, or a generated account directory. The user chooses the domain and event type; SHM resolves the managed source.

Watch the request as it happens

The access view can refresh recent traffic in the browser, making it practical to reproduce a request and see the corresponding status, path, client, and timing context. Filters and search help isolate one URI, status family, or address without hiding the raw event behind a chart.

Live here means regularly refreshed recent data, not an unbounded stream held open forever. That keeps the page responsive and the log reader bounded on busy shared servers.

Treat security events on their own terms

ModSecurity and HTTP Guard logs are separate from ordinary application errors because the response is different. A blocked request may need a precise rule review; a PHP fatal error needs application work. FTP, login, and mail-auth logs similarly answer authentication questions without mixing them into web traffic.

Keeping the source visible also prevents a security block from being "fixed" by disabling the entire protection layer. The event can be reviewed by domain, rule, path, and time before an exception is considered.

Preserve the raw evidence

SHM can list, tail, and download supported logs within the account boundary. Summaries help users scan, but raw lines remain available for exact timestamps, request IDs, response codes, and upstream messages. Downloads are streamed rather than assembled into one large in-memory response.

Log rotation and retention still apply. A panel cannot display a file the server has already rotated away or removed, and the UI should not imply permanent history. For longer investigations, export the relevant period while it exists.

Turn the event into an action

A useful log page ends with a next action: reproduce the failing URL, inspect the matching application error, review a security rule, trace an authentication attempt, or take the event into Diagnostics Center. SHM keeps those paths close so a line in a log becomes evidence, not decoration. The result is a simpler operational habit: choose the question, select the right source, narrow the time and domain, then act on the event. This sequence keeps an investigation focused on the source most likely to answer the question.