Where to look
Open Logs on a project. It has two views, and the view, the filters and the error you have open are all in the address, so you can paste a link to exactly what you are looking at.
- Requests — every request the app served for 7 days: method, path, status and how long it took. Errors are simply the failed ones: pick Errors (or 5xx) to see only those.
- App logs — what the app printed, searchable, with errors keeping their whole stack.
On the project overview, the Server errorstile opens the failed requests of the period you are looking at, and clicking a bar on the Traffic & Memory chart opens the requests from that period.
Time range and bar width
The Traffic & Memory chart on the overview and the Logs page share one time range: the last hour, 6 hours, 24 hours, 7, 30 or 90 days (the Logs page keeps 7), or Custom, an exact From and To. Clicking a bar on the chart opens Logs with that bar’s From and To filled in, so the window you are looking at is always visible and you can edit it.
The chart offers only the bar widths that make a readable chart for the range: at least 7 bars and at most 400, so a month is never drawn a minute at a time and an hour never as a single bar. Each range opens on the width that gives about 48 bars, and you can pick any other that is offered. 1, 5 and 15-minute bars exist for ranges inside the last 7 days; before the first minute we recorded, they are shaded rather than shown as empty. Older than 7 days, data is stored by the hour, so a window of a few hours that far back is widened to 7 hours and the page says so. A bar older than 7 days still shows its counts but has no requests behind it, so it does not open the log.
How errors are grouped
Two occurrences are one error when the same change would fix them. We compare the message with its variable parts replaced (ids, ports, timestamps, file paths) together with the innermost line of your code in the stack, so a different order number or a shifted line does not split an error into a hundred. A response with a 5xx status is grouped by status, method and route, so GET /orders/41 and GET /orders/42 are one error: 500 GET /orders/:id.
We recognise errors printed by Node.js, Python, Java, Go, PHP, Ruby and Rust, and structured JSON logs at error level (pino, bunyan, winston and similar). Each group shows its stack, the lines your app logged just before it, and the server events around it, such as an out-of-memory stop.
Which deploy, which commit
Every error is counted per deploy. Open an error and you see the deploy it first appeared in with its commit message and a link to the commit and to what changed since the deploy before it. If the error has not come back in the deploys after its last occurrence, we say so: that is usually the fix. An error opens from the link in the email about it, or through the MCP tools below.
Resolve, ignore, regressions
Mark resolved records the deploy that was live. If the error happens again it reopens as Regressed and we email you once. Ignore keeps an error out of the list and silences its alerts.
Emails
Error emails are off until you ask for them. Each app gets one email, ever: when we catch its first error, with a link to it. That email is the only one unless you open the error (or the Requests view) and switch on Email me about new errors.
Once it is on, we email the organization’s first member in two cases only: a new error within a day of the latest deploy, and a regression. Never per occurrence, and at most one email an hour per app, so a bad deploy that throws twenty different errors sends one email now and the rest as the hour allows. Switch it off again whenever you like.
What is kept, and for how long
- Errors — 90 days: the group, its counts per hour and per deploy, and a few samples with their stacks.
- Requests — 7 days. Errors and slow requests are always kept. Successful requests are sampled when an app serves more than 300 a minute; each row says whether it was sampled, and the traffic counts on the overview stay exact.
- App logs — 7 days. An app that prints more than 3,000 lines a minute keeps its errors and most of the rest, and the log says how many lines it left out.
- Traffic and memory — hourly for as long as your account exists, and every minute for the last 7 days.
All of it is stored on Canner’s servers in Canada, and it is removed with the project.
What is never stored
Client IP addresses, request and response bodies, and headers are not stored. Only whether a request came from a bot. Before anything is written, we remove credential-shaped values (bearer tokens, JWTs, database URLs with passwords, private keys, password=and similar pairs), the values of your project’s sensitive environment variables, the credential-bearing parts of URLs, email addresses and public IP addresses. Loopback and private addresses stay, because ECONNREFUSED 127.0.0.1:5432 is the whole diagnosis. Tokens in URL paths (a password-reset link, for example) are masked.
We cannot catch a secret your app prints in a shape nobody could recognise. Keep secrets out of your logs.
Explain this error
Where it is turned on, an error has an Explain this error button. It asks a model that runs on Canner’s own server, so your logs never leave it, for a plain-words summary, a likely cause, quotes from your logs that support it, and fix steps. We check every quote against your real logs: a quote that is not there is flagged, and the confidence is lowered when the quotes cannot be found. It is a starting point, not a verdict. Twenty explanations a day per organization.
Export
The Requests and App logs views each have CSV and Excel links that export what you are looking at, filters included, up to 20,000 rows.
For AI agents
The same data is available through Canner’s MCP server with the deployments scope:
canner_list_errors— what is wrong, grouped, with where each began.canner_get_error— one error: stack, deploy and commit, nearby server events.canner_search_logs— the app’s output or the requests, around a time.canner_deploy_history— deploys with their new, kept and stopped errors.canner_set_error_status— resolve, ignore or reopen.canner_explain_error— the on-server explanation.