> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stigg.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Observability and debugging

<Note>
  BYOC is currently in **early access**. [Contact us](mailto:support@stigg.io) to learn more or join the program.
</Note>

Stigg operates and monitors your BYOC environment. This page describes how Stigg retrieves observability data from your environment to maintain and debug it.

## Health checks

Each BYOC service exposes a health check endpoint. Stigg's monitoring infrastructure polls these endpoints continuously and alerts the on-call team if a service becomes unhealthy.

Health checks cover:

* Service-level liveness and readiness (are the services running and accepting traffic?)
* Downstream dependency health (database connectivity, queue depth, sync channel status)
* Resource utilization (CPU, memory, disk — to detect saturation before it causes impact)

## Logs

Stigg services emit structured logs. Stigg retrieves these logs from your cloud's native log aggregation service (CloudWatch Logs, Google Cloud Logging, or Azure Monitor Logs depending on your environment).

Logs are used by Stigg's team to diagnose issues and are not exported outside your cloud account. Log retention follows your cloud account's configured retention policy.

## Metrics

Stigg services emit metrics to your cloud's native metrics service. Key metrics include:

* **Ingestion rate** — usage events received per second
* **Processing latency** — time from event receipt to aggregation
* **Queue depth** — events buffered and awaiting processing
* **Sync lag** — time since last successful sync from Stigg Cloud
* **Error rates** — failed event ingestion, failed sync attempts

Stigg uses these metrics for both proactive monitoring and incident response. You can also access these metrics in your cloud's metrics console.

## Debugging

When an issue requires deeper investigation, Stigg may use **break-glass access** — a secure, time-limited mechanism (such as AWS SSM Session Manager or GCP IAP) for accessing the running containers or nodes in your environment. This access:

* Requires the IAM role granted to Stigg during provisioning
* Is audited in your cloud account's audit log (CloudTrail, Cloud Audit Logs, etc.)
* Is scoped to BYOC resources only — Stigg cannot access other workloads

You can view a log of all access activity in your cloud account's audit trail.

## Your observability stack

If you want to route BYOC metrics and logs into your own observability platform (Datadog, New Relic, Grafana, etc.), you can configure your cloud's native forwarding integrations. BYOC services emit standard structured output compatible with common log and metrics pipelines.