Self-hosted Tines operates on a shared responsibility model. Tines supports the application, but the underlying infrastructure, including the database, cache, and compute — is managed by the customer. Monitoring bridges that boundary, giving both sides visibility into what's happening and helping to identify whether an issue originates in the application or the infrastructure it runs on.
Good monitoring practice means catching problems before they affect users, understanding the cause of incidents when they occur, and making informed decisions about capacity.
What to monitor
Tines monitoring operates at two levels:
Infrastructure — the compute, database, and cache that Tines depends on, such as PostgreSQL and Redis. Alerting on CPU, memory, and availability indicates when a deployment is under stress and may need attention. See Infrastructure metrics.
Application — the behavior of Tines itself: web requests, background jobs, database queries, and calls to external services. OpenTelemetry tracing provides this visibility and is especially useful for diagnosing slow or failing stories. See Application tracing.
Event notifications
Beyond infrastructure and application health, Tines has a built-in event limit system that sends notifications when tenants, stories, or teams approach their daily event limits. Configuring these notifications is important. Hitting an event limit stops stories from running.
Event notifications are configured by tenant owners in Settings → Event limit settings. Alert thresholds can be set and notifications routed to users or webhooks.