BYOC is currently in early access. Contact us to learn more or join the program.
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
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
