Logs: builds and your site's requests
Logs tell you what happened and when: every build and publish on the project, and every request that ran your site's own code in the last day. Use them to work out why a form, a scheduled task or a page isn't behaving.
Two kinds of log
| View | What it shows | How far back |
|---|---|---|
| Builds | Every build, change and publish on this project, and the steps each went through. | The latest 40 |
| Requests | The site's requests and errors, newest first. | The last 24 hours, up to 100 at a time |
Scheduled tasks and webhooks keep logs of their own, for thirty days: Runs under Scheduled tasks and Deliveries under Webhooks. Messages sent through your forms are kept under Settings, Forms.
Builds
Each entry says what was asked (in the words of the request), who asked, when, and how long it took. When no person started it, it says Briks. On the right is its status:
| Status | Meaning |
|---|---|
| Waiting | Queued behind other work. |
| Running | Under way now. |
| Done | Finished. |
| Failed | It stopped before the end. |
| Stopped | It was stopped before it finished. |
Click an entry to see its steps, each with the time it happened. A step that went wrong is shown in red. A failed entry ends with: It did not finish. Nothing on the live site changed, and no credits were charged for it.
To see the same work as it happens, with the preview beside it, use the studio: see Watching a build.
Requests
Requests shows calls that ran your site's own code: its /api routes, and page visits while an A/B test splits visitors between two versions. Ordinary pages, pictures and files are served as they are, so they don't appear. Neither do messages sent through a contact form, which go straight to Briks rather than through your site's code.
Each line shows the time, the method and path (GET asks for something, POST sends something), how long it took in milliseconds, and the status the site answered with, or no answer. Lines your site's code wrote itself show their message and a level such as error or warning. Click a line for the full message, the date and the request's id.
| Status | What it means |
|---|---|
| 2xx, such as 200 | It worked. |
| 4xx, such as 400 or 404 | The request was turned away: something was missing or wrong in it, or nothing exists at that path. |
| 5xx, such as 500 | The site's code failed while answering. |
Filters
| Filter | Choices | Use it to |
|---|---|---|
| Search | Any words: a path, a message, a request id | Find one route or one error. |
| Level | All levels, Errors, Warnings | Show only problems the code reported. |
| Status | Any status, Succeeded, 4xx, 5xx | Show only requests that were turned away or failed. |
Set them and press Show. The page's address keeps them, so you can bookmark a filtered view. No requests in the last day means nothing ran the site's code in 24 hours. If the page says Logs cannot be read right now, try again in a minute.
Diagnose a failing form
Look for the entry
Where: Settings, Forms
Every message a visitor sends is kept here, the latest 100 on screen. Each shows when it came and from which page, then emailed, not emailed or preview.
If it says preview
Where: Settings, Forms
The site hasn't been published to production, so entries are kept but not emailed. See Publish to production.
If it says emailed but nothing arrived
Where: Your inbox
Entries go to the person who made the project, or to the workspace's first Owner if that person has left. Check that inbox, spam folder included.
If it isn't there at all
Where: The live site
The message never reached Briks. Send one yourself. If the form answers that too many messages were sent from here, a limit was reached: up to 5 messages from one visitor in 10 minutes, and up to 300 a day for the site.
If another tool should have it
Where: Settings, Webhooks, Deliveries
Set Status to Failed and press Show. Open the delivery to read what the other tool answered, then Send again once it's fixed.
Diagnose a failing scheduled task
Read the run
Where: Settings, Scheduled tasks, Runs
Open the failed run. It shows what the address answered, such as answered 500, and the start of the answer.
Find the error
Where: Settings, Logs, Requests
If the task calls a route on your site, search for its path, such as
/api/daily-summary, and set Level to Errors. The message says what went wrong in the code.Ask for the fix
Where: Studio
Paste the error into the studio chat with a sentence about the job: The daily summary route fails with this error every morning. See Making changes.
Try it again
Where: Settings, Scheduled tasks
After the fix is published, open the task's three dots and choose Run now. The result shows straight away.
A run marked Skipped didn't fail: the project's calls for the day were used up. Runs start again after midnight UTC. Plan limits are on the Scheduled tasks page.
Diagnose a slow page
Requests times everything that runs your site's code, so it is the place to look when a page that loads its content from the site's routes feels slow. Apps and dashboards usually work this way.
Open the page and note the time
Where: The live site
Load the slow page once yourself, so its requests are among the newest.
Read the timings
Where: Settings, Logs, Requests
Look at the milliseconds beside each request made at that time. One route taking several seconds while others take a few hundred milliseconds is your culprit.
Narrow it down
Where: Settings, Logs, Requests
Search for that route's path to see whether it is always slow or only sometimes, and whether Warnings or Errors appear beside it.
Ask for a fix
Where: Studio
Tell the studio which route is slow and how slow, with the page it serves.
If nothing slow appears, the delay isn't in your site's code. Pages, pictures and files are served as they are, so look at what the page carries, such as large pictures or a video, and describe what feels slow in the studio.
Worked example: a booking app that stopped saving
No new bookings had arrived since the morning, although the phone kept ringing with people saying the form did nothing.
Under Requests, with Status set to 5xx, every POST /api/bookings since 9:12 answered 500. The error line beside them said a required field was missing.
Since this morning every booking fails with a 500 on /api/bookings. The log says the pet size field is missing. We removed that field from the form yesterday.
The change was published, and the next booking under Requests answered 200.