Monitoring & Observability

Observability guidance for CARTO Self-Hosted — what to monitor, alert on, and how to integrate with your monitoring stack

This page covers proactive observability for your CARTO Self-Hosted deployment: what signals matter, recommended alerting thresholds, and how to integrate with your monitoring stack.

CARTO Self-Hosted does not ship a bundled monitoring or observability stack. CARTO services emit structured logs (JSON) to stdout/stderr and run as standard Kubernetes workloads, so they integrate with whatever logging, metrics, and alerting tooling you already operate. Collecting those logs and metrics and configuring dashboards and alerting at the infrastructure level is your responsibility — this page describes what to monitor and how to wire it into your stack.

For reactive debugging (checking pod status, enabling debug logs, or collecting a support bundle), see:

• Debug mode and logs

• Get debug information for support

---

Key signals to monitor

CARTO Self-Hosted is a Kubernetes-based platform. The following signals are the most actionable for detecting and diagnosing issues before they affect users.

Recommended alerts

Signal	Threshold	Likely cause	Action
Pod restart count	> 2 restarts in 10 min	OOM, crash loop, failed probe	Check kubectl logs for the affected pod
PostgreSQL CPU	> 80% sustained	Query load, missing indexes	Tune connection pool or scale the DB instance
PostgreSQL storage	> 80% used	Log growth, unvacuumed tables	Scale storage or enable auto-grow
Valkey memory	> 85% of maxmemory	Cache eviction pressure	Increase Valkey memory or review cache policy
API error rate	> 1% of requests	App error, bad config, downstream failure	Check maps-api and workspace-api logs
Node disk usage	> 80%	Image accumulation, log growth	Clean unused images or expand disk

Pod health quick check

# Overview of all CARTO pods
kubectl get pods -n <namespace>

# Watch for restarts
kubectl get pods -n <namespace> -w

# Events for a specific pod
kubectl describe pod <pod-name> -n <namespace>

A healthy deployment shows all pods in Running state with low restart counts.

---

Integrating with your monitoring stack

Use your cloud provider's native monitoring or a third-party observability stack to collect and route the alerts above.

Google Cloud

Use Cloud Monitoring with GKE system metrics enabled on your cluster. Key resources:

• GKE observability overview

• Enable Managed Prometheus for Kubernetes workload metrics

Recommended dashboards: GKE cluster health, PostgreSQL (Cloud SQL), Memorystore.

AWS

Use Amazon CloudWatch Container Insights for EKS clusters. Key resources:

• Container Insights for EKS

• Use CloudWatch Logs for pod log aggregation

Recommended dashboards: EKS cluster, RDS PostgreSQL, ElastiCache.

Azure

Use Azure Monitor with Container Insights for AKS. Key resources:

• Monitor AKS with Azure Monitor

• Use Log Analytics for log aggregation and alerts

Recommended dashboards: AKS cluster, Azure Database for PostgreSQL, Azure Cache for Redis.

Self-managed (Prometheus + Grafana)

CARTO Self-Hosted pods expose standard Kubernetes metrics. Use the kube-prometheus-stack Helm chart for a full Prometheus + Grafana + Alertmanager setup.

Configure ServiceMonitor resources to scrape CARTO pods, and set up alerting rules for the thresholds in the table above.

---

Log aggregation

CARTO services write structured logs to stdout/stderr, which Kubernetes captures per pod. Aggregate them with:

• GCP: Cloud Logging (automatic with GKE)

• AWS: CloudWatch Logs via Container Insights or Fluent Bit

• Azure: Log Analytics via Container Insights

• Self-managed: Loki + Grafana, ELK stack, or Datadog

For collecting logs from a specific pod, see Debug mode and logs. For generating a support bundle, see Get debug information for support.