# Monitoring

Source: https://docs.tai.ga/operate/monitoring/

Monitoring answers whether your app is healthy right now,
from the outside and from the browsers of the people using it.

It is deliberately narrow. This is a product-health view, not an observability platform:
uptime, responsiveness, and the errors real users hit.
It does not replace your infrastructure monitoring and does not try to.

## Two kinds of signal, with different setup costs

**Availability** needs one field.
Taiga checks your app's public URL every few minutes and records whether it answered and how quickly.

The field is the environment's **App URL**, and it lives in the environment's own settings:
open the product's **Integrations**, pick the environment, and set it.
That is the entire setup. Once the URL is saved, checking starts on its own,
and an environment without one says so on this page rather than sitting silently dark.

**Experience** needs a beacon in your app.
Core Web Vitals, JavaScript errors and client-observed API calls can only be seen from inside a browser session,
so something has to report them.

Until the beacon is installed, the experience signals show as not set up.
That is honest rather than blank: the data does not exist, as opposed to existing and being fine.

## Installing the beacon

Taiga generates a DSN for each environment. The DSN identifies where telemetry should go,
and it is also how Taiga knows which environment the telemetry came from.
An environment that reports with another environment's DSN shows up as that other environment.

It is write-only, which is why it is safe to commit and to ship in a client bundle.
It can be used to send data to your product and cannot be used to read anything back.

From there you have two paths. Install it yourself, or have Taiga do it.

**Set up monitoring** is offered per environment, from the environment's settings;
the Monitoring page only links there.
It needs the environment's DSN.
An environment created on its own has one from the start;
one created together with a new cloud connection, or attached by Taiga from a mirrored deployment, does not,
and setup asks you to generate it first.
It creates an initiative for that environment and adds it to the queue,
where it goes through planning, building and review like any other work.
The initiative asks for the beacon to be added to your app's entry point if it is not there yet,
for that environment's DSN to be added to a `taiga-monitor.json` file committed in your repository,
keyed by environment,
and for your build to use the entry for the environment it is deploying to.

Set up another environment later and its initiative asks only for that environment's entry.
An environment with no entry, and no DSN supplied to its build any other way, has nothing to report to,
so the beacon stays silent there:
you can ship the beacon everywhere and turn monitoring on one environment at a time.
If your app was set up before the file existed and still has a DSN in a committed env file,
environments without an entry keep reporting under that DSN until you remove it.

Having Taiga do it is usually right. It is a small, mechanical change to a codebase an agent already knows.

## Reading the page

Ordered the way the question is actually asked, not the way the system is built:
the selected environment's status first, with when it was last checked,
then one card per signal, each with its number, its verdict and a day-by-day strip.
Everything is read over a window of the last 30, 60 or 90 days, which you choose on the page.

Each environment is a tab, and each tab carries a dot for that environment's health;
any verdict other than operational is also written beside its name,
so the one that needs a look is visible before you open it.

Raw check logs never appear.
Each bar in a strip is a day;
a good day is only its color, and a bad day says how many of its checks failed or were slow.

One property worth trusting: a status Taiga cannot currently verify shows as not checked,
not as the last thing it knew.
If checks stop arriving, the light goes gray rather than staying green,
because a stale green is the one you would act on.

## New apps say so

A brand-new environment shows as baseline learning rather than green.

This is a real distinction and worth trusting.
A green light that means "nothing has gone wrong in the four minutes we have been watching"
is worse than no light, because you would act on it.