A public status page at status.logpulse.io is planned for Q3 2026. The status page will display real-time platform health, historical uptime, ongoing incidents, and scheduled maintenance windows. Subscribe to receive notifications about incidents affecting your region.

LogPulse provides at-least-once delivery. Every log event accepted by the API (HTTP 202 response) is persisted in the Redis-backed ingest queue before the response is sent. If ClickHouse is temporarily unavailable, events remain in the queue and are retried automatically. In rare failure scenarios, an event may be written to ClickHouse more than once.

The batch writer accumulates incoming events and writes them to ClickHouse in batches of 100 to 1,000 events. A flush is triggered either when the batch reaches the target size or after a 5-second idle timeout, whichever comes first. This balances write efficiency with ingestion latency -- most events become queryable within 5 seconds of being accepted.

When a batch insert to ClickHouse fails, the batch writer retries with exponential backoff. Failed events are retried up to 5 times with increasing delays (1s, 2s, 4s, 8s, 16s). After all retries are exhausted, events are moved to a dead-letter queue (DLQ) for manual inspection and replay.

When the ingest queue approaches capacity, LogPulse applies backpressure to protect data durability. At 80% queue depth, a warning is logged internally. At 100% queue depth, the API begins returning HTTP 429 (Too Many Requests) with a Retry-After header indicating when to retry.

Daily ingestion quotas are enforced separately from queue-based backpressure. When your organization reaches 80% of its daily quota, organization Owners receive an email notification. At 100%, ingestion is throttled and excess logs are queued for up to 1 hour. If the quota is not increased, queued logs are discarded.

When a rate limit is exceeded, the API returns HTTP 429 with the following headers:

HTTP/1.1 429 Too Many Requests
Retry-After: 12
X-RateLimit-Limit: 10000
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1711929600

Rate limits use a sliding window algorithm that allows short bursts above the per-minute limit. A burst of up to 2x the per-minute limit is allowed for up to 10 seconds, as long as the rolling 1-minute average stays within the limit. This accommodates deployment spikes and application restarts without dropping logs.

Each organization has independent rate limits and quotas. One organization's traffic cannot starve another organization's resources. Rate limits, query concurrency slots, and ingest queue capacity are allocated per tenant at the application layer. On the storage layer, ClickHouse queries are subject to per-query memory limits and timeouts that prevent any single query from monopolizing cluster resources.

As a rule of thumb, keep indexed attributes below 100,000 distinct values per field. Fields exceeding this threshold should be stored in the event body and searched with full-text queries rather than attribute filters.

// Good: low-cardinality attributes for filtering
{
  "event": "User login failed: invalid credentials for [email protected]",
  "level": "warn",
  "source": "auth-service",
  "attributes": {
    "environment": "production",
    "region": "eu-west-1",
    "error_type": "invalid_credentials"
  }
}

// Bad: high-cardinality values as attributes
{
  "event": "Request processed",
  "attributes": {
    "request_id": "550e8400-e29b-41d4-a716-446655440000",  // Too many unique values
    "full_url": "https://api.example.com/users/12345?page=3", // Unbounded
    "stack_trace": "Error: timeout at Object.<anonymous>..."   // Unbounded
  }
}