Internal page

The Internal page shows request traffic reported by your own servers, alongside the status of the services your public page monitors. Use it to find failing endpoints and services that have stopped reporting. Open Dashboard → Internal; the account needs Internal analytics.

This page is private to your team. Reported traffic does not publish an incident automatically.

Database Health is a separate optional feature for native database checks and application pool reporting. It does not replace the error heatmap.

Getting data into it

Send batches through the Event API using an ingest-scoped key. Its reference covers authentication, fields, batching limits and error responses. The v2 interface adds a stable reporter identity and heartbeat reports, so an idle service can still show that it is reporting.

Send route templates such as /v1/orders/:id. A raw path such as /v1/orders/8837 creates a separate endpoint for each order and can exhaust your endpoint allowance.

What it shows

The briefing compares reported traffic with your public status. The fleet map and service table show the same selection. Search or filter by service, region, team, response status, method or route prefix, then select a service to inspect its endpoints.

The table shows requests, errors, error rate, average latency and p95 where measurements support it. You can change its ordering and inspect healthy services as well as failures.

Choose the last hour (the default), 6 hours or 24 hours. Select a time range to narrow the investigation, or pin the view and copy a link for a teammate. A pinned view stops polling. InBrief event storage retains 14 days of traffic.

Where your events are stored

By default they live in our database: 14 days at one-minute resolution, included, nothing to configure.

To store event history in your own warehouse, open Dashboard → Settings → Storage. This needs External event storage. Supported adapters are BigQuery, ClickHouse (Cloud or self-hosted) and Snowflake. Postgres, MySQL and Redshift are not supported destinations.

Primary event store	Traffic written to	Traffic read from	History retention
Our storage (default)	our database	our database	14 days, fixed
Your warehouse	your warehouse	your warehouse	whatever you set

The selected store owns event history. InBrief also retains reporter identity, region, team and reporting timestamps locally to track ingestion, plus encrypted connection credentials. Reporter metadata has no automatic expiry. Failed warehouse writes are buffered locally as aggregated batches under the limits below; this buffer is not a second complete event history.

What changes when you switch

You create the table. The settings page shows the exact DDL to run, and we never create tables in your account; the credential you hand us should reach that one table and nothing else in the project.

History does not move with you. What is already in our storage stays there for the rest of its 14 days, and your warehouse starts from the moment you switch. The page also drops to polling every 60 seconds instead of 15, because each poll is now queries billed to your account.

If the warehouse stops answering, the page reports that it is unavailable. An accepted batch waiting for delivery returns 202 with a warning. Buffering is bounded: at most 2,000 batches per status page, with older batches removed above that cap. Delivery stops after 50 failed attempts; exhausted batches become eligible for deletion seven days after their creation.

Events can be lost if these limits are reached. Switching back to InBrief storage discards pending external batches. Restore the warehouse connection before switching, and check that recent traffic arrives. Keep your own source records if you need to recover gaps; automatic replay stops at the retry limit.

Retries can also produce duplicates after a timeout. A deduplication key accompanies each batch, but provider deduplication is bounded. Duplicates can inflate request and error counts.

Full detail, including the retention and cardinality limits, is in the Event API reference.

Reading service states

A reporter with errors in the selected window is failing, regardless of its error rate. Without errors it is late after the greater of two minutes or three expected reporting intervals, and silent after ten minutes. Otherwise it is clean. These states describe reported traffic, not the public page's uptime verdict.

Without a v2 heartbeat, reporting health is estimated from traffic. No requests can mean an idle service, so missing traffic alone does not prove it is offline. Fewer than 100 requests in the window is marked thin; read its error rate with that sample size in mind.

Comparing traffic with public status

Signal	What it means
The gap	Your status page is green and your traffic says otherwise. The page names the service responsible and offers to open an incident.
No monitor	A failing endpoint with nothing watching it. Tagged in place, so you can see which failures your public page knows nothing about, and which are worth adding a monitor for.
Stopped reporting	A service that was reporting and went quiet. Called out separately, with an estimated reporting state when no heartbeat is available.

From here to your public page

With incident-publishing access, select a service and publish an incident after reviewing its text and affected services. Translation and subscriber delivery use the capabilities enabled on your account. Alert rules are configured separately from public incident publishing. See Incidents & maintenance.

Next up