--- title: "Logs: builds and your site's requests | Briks" url: https://briks.dev/docs/logs description: "Read the build log and the last day of your site's requests, filter by level or status, and track down a failing form, a failing job or a slow page." last_updated: 2026-10-08 --- # 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. 5 minute read Checked against the studio on 8 October 2026 ## Two kinds of log Where 1. Projects 2. Your project 3. Settings 4. Logs | 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](https://briks.dev/docs/crons) and **Deliveries** under [Webhooks](https://briks.dev/docs/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](https://briks.dev/docs/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 1. 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**. 2. 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](https://briks.dev/docs/publish-to-production). 3. 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. 4. 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. 5. 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. Forms that save to your database A form that saves into your database, such as a booking request in an app, runs your site's own code. Its sends do appear under **Requests**: search for its path and set **Status** to **5xx** to find the ones that failed. ## Diagnose a failing scheduled task 1. 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. 2. 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. 3. 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](https://briks.dev/docs/making-changes). 4. 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](https://briks.dev/docs/crons) 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. 1. Open the page and note the time Where: The live site Load the slow page once yourself, so its requests are among the newest. 2. 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. 3. 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. 4. 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 What the owner noticed A dog grooming salon in Leeds > 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. Asked in the studio > 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. ## Read next - [Data and automation **Scheduled tasks** Run a scheduled task on your site at set times: a morning summary, a weekly tidy up. Write a schedule, read each run, fix one that fails, and see plan limits.](https://briks.dev/docs/crons) - [Data and automation **Webhooks** Send a signed message to another tool when your site is published, a form is sent or a record changes. Payloads, signatures, retries and deliveries explained.](https://briks.dev/docs/webhooks) - [Your site's features **Forms** Add a form to your Briks site, test it in preview, find every entry in the studio, get each one by email in production and pass them on with a webhook.](https://briks.dev/docs/forms) - [Help **Troubleshooting** What to do when something in Briks is not working: signing in, credits, builds and changes, domains, forms, email, the chatbot, data and teams.](https://briks.dev/docs/troubleshooting) Still stuck? Write to [hello@briks.dev](mailto:hello@briks.dev) with your project's name and what you expected to see. A screenshot helps.