Providers
A Provider is how Firetiger represents external infrastructure or a dependency that a customer’s system relies on: a cloud account, database, data store, SaaS API, AI API, or similar system. Providers sit beside Services in the catalog. A Service is software the customer owns; a Provider is something that software depends on.
Providers help Firetiger answer questions like:
- Which Services depend on AWS, GCP, Postgres, or ClickHouse?
- Do we have the right Connection to observe this dependency?
- Are there Provider-owned Objectives that monitor the dependency directly?
- When a Service is unhealthy, could an upstream Provider explain the scope?
For field-level API detail, see the Providers API reference.
Providers and Services
A Service is a customer-owned component such as checkout-api or
billing-worker. A Provider is an external system those Services depend on,
such as aws, postgres, or openai.
The relationship is intentionally loose. Provider dependencies are recorded as
catalog knowledge, usually in the Provider’s context field or in a Service’s
context, rather than as a hard schema edge. That lets agents capture the real
architecture even when the dependency evidence comes from traces, configuration,
logs, code, or operator notes.
Provider types
Each Provider may have a provider_type, such as PROVIDER_TYPE_AWS,
PROVIDER_TYPE_GCP, PROVIDER_TYPE_POSTGRES, or PROVIDER_TYPE_CLICKHOUSE.
The type drives UI branding and lets Firetiger recommend the Connection kinds
needed to observe the Provider.
Some Provider types are observable today because Firetiger knows which Connection can measure them. Others are context-only: they are still useful catalog knowledge and investigation evidence, but Firetiger may not yet offer a direct monitoring path for them.
Connections
A Connection is the credentialed integration Firetiger uses to inspect data: cloud monitoring, databases, telemetry stores, APIs, MCP servers, and similar systems. Providers and Connections are related but not the same thing:
- A Provider is the dependency being represented, such as “production Postgres”.
- A Connection is how Firetiger can query or call into something, such as a Postgres connection or a cloud monitoring integration.
GetProviderRecommendations returns recommended Connection types for a
Provider. It does not create or mutate Connections.
Provider Objectives
An Objective may be owned by a Provider by setting owner_resource to the
Provider name, for example providers/postgres. Provider-owned Objectives are
used when Firetiger monitors the dependency itself rather than one customer
Service that uses it.
Provider-owned Objectives follow the same Objective and Indicator model as Service-owned Objectives:
- The Indicator queries telemetry or provider data.
- The Objective sets the health promise.
- The Objective’s trigger decides when a sustained breach is serious enough to become unhealthy and drive an Investigation.
Provider-owned monitoring is useful for dependency health signals such as database availability, connection saturation, replication lag, cloud API errors, or queue backlog. If the signal really describes a customer-owned component’s user experience, model it as a Service Objective instead.
Lifecycle
Providers flow through the same recommendation lifecycle as Services:
| State | Meaning |
|---|---|
| Recommended | An agent detected the Provider and is asking the customer to accept or dismiss it. |
| Active | The Provider is accepted or user-created and participates in catalog reasoning. |
| Archived | The Provider recommendation was dismissed or hidden. |
Archived Providers are retained for history but skipped by active Provider surfaces and expert sweeps.
Provider Expert
Each active or recommended Provider may have a provider-expert session in its
expert_session field. The Provider Expert is a long-lived Resource Expert for
that one Provider. It answers questions from the Provider detail page and is
woken periodically to refresh its understanding of dependencies, Connections,
existing Provider-owned Objectives, and telemetry evidence.
The session can be replaced over time; the Provider’s expert_session points to
the current session while older sessions remain in history. The Provider itself,
not any one session transcript, is the durable source of truth.
Modeling guidance
Use a Provider when the concept is an external dependency. Use a Service when the concept is customer-owned software or a customer-owned workflow. When in doubt, ask: “Can the team deploy, roll back, or change this component directly?” If yes, it is usually a Service. If not, it is usually a Provider.
Provider context should capture:
- What the Provider is and what type it is.
- Which Services or workflows depend on it.
- Which Connections can observe it.
- Where relevant telemetry lives.
- Known gotchas, limits, maintenance windows, or failure modes.
That context is useful to humans in the UI and to Firetiger agents during investigation and monitoring design.