Services
A Service is how Firetiger represents a component of your system — an API server, a worker, a checkout flow — and monitors whether it is healthy. Services are the system map Firetiger’s Agents reason about: who owns what, where a problem’s blast radius is, and which parts of your system are involved in a given investigation.
Firetiger measures a Service’s health through a small chain of concepts that build on each other:
- A Service is broken down along one or more Dimensions (environment, region, cloud, …).
- An Indicator turns your telemetry into a measurement over time.
- An Objective sets a target on that measurement — a plain-English health promise.
- Each combination of Dimension values is a Service Cell, evaluated independently.
- The result of evaluating a Cell against its Objective is its Cell Health.
The rest of this page walks through each concept and how they fit together. For the API and field-level detail, see the Services, Indicators, and Objectives API references.
What is a Service
A Service is a conceptual software component that Firetiger observes and explains — for example, your checkout API or your billing-worker. It is the thing a developer recognizes and talks about (“the checkout service is slow”).
A Service is deliberately not tied to a single running instance, container, or replica. The same Service is often deployed in many places — multiple environments, regions, or clouds — each with different failure boundaries. So the Service itself is not necessarily the unit whose health moves together: one environment can be perfectly healthy while another is degraded. Firetiger captures that nuance with Dimensions and Service Cells, below.
Each Service carries a short human description and an agent-maintained deep-dive (context) that records what the Service does, where its telemetry lives, and what “normal” looks like — knowledge agents draw on when they investigate it.
Dimensions
A Dimension is an axis along which a Service’s health is meaningfully broken down — its deployment shape. Common Dimensions are environment (production, staging), region (us-west-2, eu-central-1), cloud, or cell.
Dimensions are catalog metadata: they describe how a Service splits up, so health can be reported per environment or per region instead of as a single blurry number for the whole Service. A Service can have several Dimensions at once — for example, both environment and region — and their combinations define the units Firetiger evaluates independently (see Service Cells).
Indicators
An Indicator is the measurement behind a Service’s health: a query that turns your telemetry into a number over time — a latency, an error rate, a success ratio. It is what an Objective watches.
An Indicator can bind to one or more of a Service’s Dimensions. When it does, each row the Indicator returns carries its Dimension values (such as environment=production, region=us-west-2), and those values are what identify the Service Cells an Objective evaluates separately. An Indicator with no bound Dimensions produces a single, Service-wide measurement.
Objectives
An Objective is a health promise for a Service, expressed as a target over one backing Indicator. It pairs a plain-English statement of intent (for example, “checkout stays fast and reliable for our users”) with a machine-checkable target, and Firetiger evaluates it continuously.
There are two kinds of target:
- Ratio — a share of events must stay good, for example “99.9% of requests succeed.”
- Gauge — a measured value must stay within a threshold, for example “p99 latency stays under 300 ms.”
An Objective is a single resource even when its backing Indicator is dimensional and it ends up evaluating many Service Cells. That matters for how problems are reported: one Objective produces one health story, with affected Cells called out as scope rather than as many separate Objectives.
An Objective does not flip to unhealthy the instant a single data point grazes its target. Each Objective carries an alerting trigger that decides when a breach is serious enough to count: the measurement must stay past the target by a configurable multiplier, and stay there across both a long and a short evaluation window. A multiplier of 1× means “right at the target”; a higher multiplier adds margin so only meaningful, sustained breaches trip the alert. For example, a “99.9% success” Objective (a 0.1% failure target) with a 14.4× multiplier is flagged when the failure rate stays above ~1.44% — not at the first request over 0.1%. New Objectives also calibrate against your recent telemetry to suggest a confident target before they begin alerting. See the Objectives API reference for trigger, multiplier, and calibration detail.
Service Cells
A Service Cell is one blast-radius unit of a Service: a concrete part of its deployment whose health can be monitored and measured independently. A Service Cell is identified by a set of Dimension values — for example environment=production and region=us-west-2. Each distinct combination the backing Indicator returns is its own Cell.
When an Objective’s Indicator binds Dimensions, Firetiger evaluates the Objective once per Service Cell. This is what lets Firetiger say “checkout is unhealthy in us-west-2 production, but fine everywhere else” instead of collapsing every deployment into a single pass/fail. After first mention, these are usually just called Cells.
A Cell is a health concept, not a chart artifact. It is distinct from a time-series “series” (how data may be drawn on a graph): a Cell is the unit Firetiger monitors and reasons about independently.
Cell Health
Cell Health is the result of evaluating one Service Cell against its Objective. Each Cell resolves to one of three states:
| State | Meaning |
|---|---|
| Healthy | The Cell has not stayed past the Objective’s trigger threshold across both windows — it can sit somewhat past the raw target and still be healthy until it crosses that threshold. |
| Unhealthy | The Cell stayed past the Objective’s trigger threshold — its target adjusted by the trigger multiplier — across both the long and short evaluation windows, so a brief blip doesn’t flip it. |
| No data | There isn’t enough telemetry in the window to judge the Cell. |
An Objective rolls its Cells up into an overall health: it is unhealthy if any evaluated Cell is unhealthy, healthy when Cells have data and none are unhealthy, and no data when nothing could be evaluated. In the Objective view, the per-Cell breakdown is shown as the Cell health panel.
An unhealthy Cell describes the affected scope of a problem — which environment or region is hurting — inside a single Objective’s health story. Unhealthy Cells are evidence an Agent uses to scope and explain an issue; they are not separate Objectives or separate alerts.
How it fits together
Putting the chain together with an example:
The checkout Service looks unhealthy. Does that mean every deployment of checkout is broken?
Not necessarily. Health is evaluated per Service Cell whenever the Objective’s Indicator binds Dimensions. If the Indicator returns environment=production and region=us-west-2, that combination is one Cell. If only that Cell stays past the Objective’s trigger threshold, it becomes an unhealthy Cell — the affected scope — while the rest of checkout stays healthy.
The Objective remains a single Objective; the unhealthy Cell is the blast radius and the evidence an Agent investigates from. That is the whole point of the model: a Service is the component you recognize, Dimensions describe how it is deployed, an Indicator measures it, an Objective sets the promise, and Service Cells with their Cell Health tell you exactly where that promise is or isn’t being kept.
To configure these resources via the API, see the Services, Indicators, and Objectives references.