Errors

The Errors section of your app's Monitoring tab gathers the exceptions your app raises and the errors your visitors' browsers report into error groups: one row per kind of failure, with when it was first and last seen, how often it happened, how many requests or visitors it touched, samples to look at, and a state you control. When a new kind of error appears, or a fixed one comes back, your organization is told.

Turning it on#

Error groups come from two measurement switches. Turn on either or both:

• Measure inside the app (the Inside the app section of Monitoring, container apps) sends your app's traces to Nimbus Land. Every request or job that fails becomes a server error. If your app's OpenTelemetry SDK also exports log records, those at error level or above that carry an exception count too (see Logged exceptions).
• Measure visitors in the browser (the Analytics tab, container apps and static sites) adds a small script that reports JavaScript errors from visitors' browsers. See Traffic and analytics.

With neither switch on, the Errors section says so and links to both. Errors that only appear in your app's printed log output are not grouped.

What an error group is#

An error group is every occurrence of the same failure, counted together. Each group has a kind:

• App exception: a request or job of your app failed (it raised an error or answered with a 5xx). The group is the request's route (GET /orders/:id, or a job name) together with its cause: the first operation in the request that recorded an exception or error message. A failed request with no recorded cause is still a group, titled with its status (HTTP 500).
• Upstream call: a call your app made to another service failed while the request around it did not, or outside any request. The group is the call named with its host (GET api.partner.test) and its message. A failing call that made the request fail is the cause of that request's app exception group instead.
• Platform noise: see Platform noise.
• Browser: JavaScript errors, unhandled promise rejections and failed resource loads, grouped by error type, message, script path and line.

The same exception in two different routes makes two groups. Parts of a message that change every time (record ids, quoted values, numbers, addresses) are set aside before grouping, so Order 123 not found and Order 456 not found are one group. The group's title shows the normalised message.

New server errors appear within about two minutes.

The Errors section#

The section lists the groups seen in the same window as the Traffic section (1 hour, 6 hours, 24 hours or 7 days), newest first. Each row shows:

• the source (server or browser) and, for server groups, the kind;
• the title: the exception type and normalised message, HTTP <status>, or the browser message;
• the location: the route, the call with its host, or the script path and line;
• the environments it was seen in (production, a preview, staging);
• when it was first seen (possibly before the window) and last seen;
• the count of occurrences in the window, and how many requests (server) or visitors (browser) were affected;
• its state: open, resolved, regressed or muted.

Muted groups and platform noise groups sit under their own folds at the bottom, so they don't hide what is new. Groups from every environment are listed together, each row naming where it was seen.

The error page#

Choose a group to open its page. It shows the group's details, an hourly trend over the selected window, the latest sample and up to 20 recent samples.

• A server sample is the failed request laid out on a timeline, with the operation that caused the failure highlighted, and its exception type, message and stack trace.
• A browser sample shows the page the visitor was on, their device, the time and the stack trace as the browser reported it.

Samples are kept for 7 days and the hourly counts for 30 days, so a group whose last occurrence is older than a week still shows its trend but no samples. Titles, messages and stack traces are your app's own content and are visible only to members of your organization; keep secrets out of exception messages.

Resolve and mute#

You set a group's state from the Errors section or the error page.

• Resolve (Mark resolved on the error page) says the problem is fixed. If the error happens again, the group comes back as regressed and your organization is told, as for a new group.
• Mute stops notifications for For a day, For a week or For good. A muted group keeps counting and keeping samples but opens no incident. When the period ends it is open again. Unmute ends it early.

Only members who can manage the app can resolve, mute and unmute; others see the state without controls. Every change is recorded in your organization's audit log.

A group not seen for 30 days leaves the list, but its state is remembered: if it reappears, a resolved group comes back as regressed.

The New error alert#

Alongside Down, Errors and Slow (see Traffic and analytics), every app has a New error alert. It is on by default and has no threshold. An incident opens when:

• a group is seen for the first time, in any environment, or
• a resolved group is seen again.

The incident closes when the group is marked resolved or has been quiet for 24 hours. Muted groups and platform noise never open incidents. Unlike the other alerts, New error watches previews and staging too.

The first hour is quiet. When you turn a measurement switch on, every error your app was already raising becomes a group at once. Groups first seen in the hour after the switch was turned on are listed but not announced.

Who is told. Your organization's owners and admins are emailed. Notification destinations in your organization settings can subscribe to A new kind of error (the alert.new_error event); a delivery carries the group's title, source, environment and a link to its error page, never stack traces or sample contents. The daily cap of 10 alert notifications per app per UTC day is shared with the other alerts.

The Errors alert names what threw. When the Errors alert (the share of failed requests) opens for an app with Measure inside the app on, its notification lists up to three app exception groups seen in the last hour, with links to their error pages.

Logged exceptions#

If your app's OpenTelemetry SDK exports log records (for example Node apps using pino or winston instrumentation, or Python's logging bridge), every record at error level or above that carries an exception becomes an app exception group, keyed by the exception's type and normalised message and:

• by the request's route, when it was logged while handling a request;
• otherwise by the logger's name (payments.sync), or log when it has none.

Other log records are dropped. Records sent this way don't appear in your app's logs, which keep showing what the app writes to standard output, so nothing is shown twice.

Platform noise#

OpenTelemetry SDKs try to describe where they run by calling cloud providers' metadata addresses, which don't exist on Nimbus Land, so those calls fail. For Node apps with Measure inside the app on, Nimbus Land sets OTEL_NODE_RESOURCE_DETECTORS=env,host,os so the SDK skips those calls.

Any remaining failed call to metadata.google.internal, 169.254.169.254, fd00:ec2::254, 100.100.100.200 or 169.254.170.2 is a platform noise group. Noise groups keep counting and can be opened, resolved and muted, but they sit under their own fold, never open a New error incident, and are left out of the CLI, the API and Claude unless you ask for them.

Source maps#

Browser errors arrive with positions in the file the browser ran, usually a minified bundle. For a static site that Nimbus Land builds (a Vite site, for example), if its build produces source maps, the .map files are kept aside at publish time: stored privately, never served from the site's address. Each frame of a browser sample that has a map is shown with the original file, line and column, marked as mapped. Maps are kept as long as the release they belong to is in your release history.

Container apps, and sites built elsewhere and uploaded, show positions exactly as the browser reported them.

Daily allowances#

Error groups follow each measurement's daily allowance. When an app goes over its daily allowance for traces or for browser reports, Nimbus Land stops keeping detail for that source until the next UTC day: groups keep counting, no new samples are kept, and the error page says so. Recording resumes on its own.

From the CLI, the API and Claude#

nimbus errors                        # groups seen in the window (--muted, --noise to include them)
nimbus errors show <fingerprint>     # one group: trend and samples with stack traces

The HTTP API answers GET /api/v1/apps/:id/errors and GET /api/v1/apps/:id/errors/:fingerprint, and the Claude connector offers list_errors and get_error. These are read-only: resolving and muting stay in the console. Error messages and stack traces are your app's own text, passed through unchanged, so treat them as data when you hand them to another program.

What is not covered#

• Errors that only appear in printed log output.
• Assigning groups to people, comments, or issue-tracker links. Resolve, mute and the audit log are the whole workflow.
• Uploading source maps for container apps.
• Linking a browser error to the server request behind it. They are separate groups.