Reading logs

When a website does something odd, the answer is nearly always in a log. Who came by, what the server sent back, where PHP tripped over itself. In CoreCP you read those logs straight from the panel — no SSH session to open, no file to download.

Nothing of yours is stored centrally. The lines stay on the server that wrote them; the panel fetches them at the moment you look, and throws them away afterwards. That is a deliberate choice: the fewer places your visitors' data sits, the better.

Where to find them

Go to your account and open the Logs tab. The filters are along the top and the lines themselves are underneath.

Administrators have a second door: a server's page carries a View logs button under Quick actions. That one shows the whole machine's logs rather than one customer's.

Which log you want

Pick what you want to look at under Log. As a customer you get five:

Visitors to a website — every request the web server answered: the address it came from, the moment, the page asked for and the status code. This is the log that tells you whether that one visitor really did get a 404, or whether a search engine is crawling your site.

Errors of a website — what the web server itself had to say. A file it could not find, a PHP process that stopped answering, a permission problem on a folder.

PHP errors — everything PHP wrote down itself, across all the PHP versions you use, in one stream. So you do not need to know whether that site runs 8.3 or 8.5: both are here, each line labelled with the version that raised it.

Slow database queries — questions to the database that took too long. Only those from your own database users; the ones belonging to other customers on the same server are never shown to you.

Scheduled jobs — what your cron jobs did, and what they printed.

Some logs need to know what they are about. For the two website logs you therefore pick a website beside the log itself.

Filtering: the actual work

A busy site's log is thousands of lines long. The three filters along the top exist to turn that into something readable, and they run on the server itself — so you only fetch what you asked for.

Level

Under Level, choose how bad something has to be before you want to see it. Pick Error and you get errors and everything worse; warnings and ordinary notices disappear.

Watch what "level" means per log — the panel puts the sentence underneath as a hint:

• For errors of a website and for PHP errors the level comes out of the line itself. A PHP Fatal error is critical, a PHP Warning is a warning.
• For visitors to a website the log format has no level at all, so we derive one from the status code: a 500 is an error, a 404 a warning, the rest is traffic. That is also the quickest trick on this page — set the level to Error and you see every 500 of today at a glance.
• For slow database queries there is no level; every line counts as a warning.

Period

Under Period, choose how far back to look: the last quarter of an hour, the last hour, today, the past week, or everything there is. This is the filter you reach for first when the report is "it went wrong around ten this morning".

Contains text

Type a fragment into Contains text and press Apply. You get only the lines that contain it. Capitals do not matter. Useful for a path (/contact), an address, or part of an error message.

The three compose. "Every error in the last hour on /checkout" is simply: level Error, period Last hour, text /checkout.

Following live

Turn on the Follow live switch and the screen stays open: new lines appear at the bottom as they are written. A green dot marked Live shows in the header for as long as the connection holds.

This is how you reproduce a problem. Turn it on, refresh your site in another tab, and watch your own request arrive — usually within a second.

Two things you will notice:

• The lines already on your screen stay exactly where they are. Nothing slides, nothing jumps. The new line lights up briefly and fades.
• The view only scrolls along if you were already at the bottom. If you are reading back through something, it stays where you are reading.

The filters keep applying while you follow. Set the level to Error and only errors arrive — no hundred lines of images and stylesheets in between.

Close the tab or turn the switch off and following stops by itself. Nothing is left running on the server.

Downloading

Press Download and you get exactly what is on your screen as a text file, with the same filters applied. What you read is what you get.

The first few lines of the file start with a #: which log it is, which website or account it belongs to, when you fetched it and with which filters. Handy when you forward the file to whoever built your site — they know immediately what they are looking at.

How long it is kept

Under the Lines heading there is a single sentence giving the retention of the log you have open. For example: rotated weekly, 8 kept, compressed — the web server logs are rolled over weekly and eight weeks are kept.

That period is a server setting, not yours, and you cannot change it here. We show it because the answer to "why do I see nothing from last month" is in it.

Seeing nothing when you expected something? Walk these three:

1. Is the period too tight? Set it to Everything there is for a moment.
2. Is there still a text filter in place you had forgotten about?
3. Does what you are after fall outside the retention above?

From the command line

If you have SSH access you can ask for the same thing from your own account. You only ever see your own hosting:

# Which logs do I have, and how long are they kept?
corectl logs sources

# The last 300 requests to a site
corectl logs tail web-access --domain yourdomain.com

# Only what went wrong, in the last hour
corectl logs tail web-error --domain yourdomain.com --level error --since -1h

# All your PHP errors, every PHP version together
corectl logs tail php --lines 100

# Your own slow database queries from the past week
corectl logs tail db-slow --since -7d

--since takes both a moment (2026-08-12T09:00:00Z) and a duration back from now (-2h, -30m, -7d). Add --json for machine-readable output, for instance to count something yourself.

What you do not see, and why

Some logs are deliberately not yours: the server's mail logs, its security logs and the journal of individual system services. Those describe the whole machine and name every customer on it while doing so — there is no version of that log that is only about you. Server administrators do see them.

If you want to know where one e-mail message ended up, use Mail delivery in your account's e-mail section. That screen shows exactly your own post, and nobody else's.