Guide 12 · Developer docs

Performance, caching, deployment and go-live

How Core dna caches pages, what makes a render fast, how code reaches a site and what stays behind, the go-live checklist, and running a site once it is live. For developers, leads and site operators who already build pages in a theme repository.

L2–L3
Unit 06 · Running a site after launch

Reading the error log and tracing a request

What the Template Errors screen records and what it leaves out, narrowing it to one site and one time window, the fields of an entry, and tracing one visitor's failing request from a vague report to the template that failed.

Who this is for. The developer on support who has a report such as "the form doesn't work" and a live site that shows only its error page. Afterwards you can find that request's entry among the day's errors, read every field, and reproduce it where the stack trace is visible.

What the error log records

The admin's Template Errors screen (/cdna-admin/sites/errors) lists errors raised while the platform rendered a page for a visitor:

  • PHP errors and warnings raised inside a template, such as reading a key that does not exist, with the template file named.
  • Any exception thrown while a page was being rendered, the ones that end in the site's error page.
  • A few notices the platform records for site builders, such as a page path or an image path that was not found.

It does not hold API requests, admin screens, background tasks or job runs, and a request the page cache answered never reaches it. The line number is dropped from template errors, because it would point into the compiled copy of the template rather than the file you edit; the template's name and the message are what you have.

Narrowing to one site and one time window

The screen has two filters: the site, all sites of the account unless you choose one, and the range, counted back from now: 5, 15 or 30 minutes; 1, 2 or 8 hours; 1, 2, 5, 7 or 14 days. Errors older than 14 days are not shown. The filters are kept in the address, so a link to one site's last hour, /cdna-admin/sites/errors?site=12&range=3600, can be shared with whoever is helping.

Narrow by site and range first, then search the list for the hostname or the path: each entry's URL carries the hostname.

What an entry holds

The list shows each error's time and message. Opening one shows its fields:

FieldWhat it holds
timestampWhen it happened, in the admin's time zone and date format
messageThe error text, with server paths removed
templateThe template file the error came from, when it came from one
url, pathThe full address, hostname and query string included, and the path with its query string
methodGET, POST and so on
referrerThe page the visitor came from, when the browser sent it
dataThe submitted form fields, with password, confirmPassword, currentPassword and client_secret replaced by ***
userThe username of the visitor, when they were signed in
level, severityHow serious the platform judged it
An entry can identify the visitor

The log keeps no session id, but user names a signed-in member, and data holds whatever the form collected: names, email addresses, street addresses. Match a report to its entry by time, URL and referrer, not by asking who the person is, and do not paste entries into tickets or chat without removing those fields.

Tracing one failing request

  1. Get three facts from the person who saw it: the exact address, the time to the minute, and what they did just before. A screenshot of the page with the address bar visible gives the first two.
  2. Open Template Errors for that site, with the shortest range that still covers the time.
  3. Find the entry for that path at that minute. For a form, the method is POST and data shows what was submitted; the referrer is the page the form was on.
  4. Read the template and the message. Most template errors name the variable or method that was missing; the same message on many entries is one fault, not many.
  5. Reproduce it on a development environment with the same address, method and fields. In development mode the error is shown on the page with its stack trace.
  6. Confirm it worked on production by repeating the request and checking that no new entry appears for that path.

Never ask a member for their password to reproduce a problem. When the failure needs their account, reproduce it with a test account in the same groups, or ask an administrator to look at the member's record.

When there is no entry

If nothing matches the path and the minute, the failure was not a rendering error. In order:

  • A stale page: the page cache answered, so nothing rendered. Read the response's cache headers (reading the headers).
  • A request from JavaScript: an API call answers with its own error body; read it in the browser's network panel (Responses and errors).
  • Something that happened afterwards: a notification or an export is a job, so read its job runs; an email is in the Mailer batches; a payment is in the provider's dashboard.
  • A request that never reached the platform: ask Core dna for the server log for that hostname and minute.
Go deeper

Was this page helpful?

Your answer goes to the docs team.