Health Monitoring#

Health checks answer whether a connection works right now. Monitoring answers the ongoing questions: is traffic flowing, are webhooks being delivered on time, and did anything error overnight. Outeract exposes this through three surfaces: the unified stats query, per-entity logs, and webhook delivery/timing queries.

flowchart LR
    E["Events"] --> S["stats query<br/>(time-bucketed counts)"]
    L["Logs"] --> S
    L --> GL["logs query<br/>(per-entity detail)"]
    D["Webhook deliveries"] --> WS["delivery + timing<br/>queries"]
    S --> M["Your monitor /<br/>console dashboards"]
    GL --> M
    WS --> M

The stats Query#

stats returns time-bucketed counts for any monitorable source. It is available on the developer API (https://api.outeract.com/, API-key auth), which makes it the backbone for external monitors.

query {
  stats(
    sourceType: EVENT
    startDate: "2026-07-13T00:00:00Z"
    endDate: "2026-07-14T00:00:00Z"
    granularity: HOURLY
  ) {
    timestamp
    count
  }
}

Source types:

Granularities: ONE_MINUTE, FIVE_MINUTE, FIFTEEN_MINUTE, HOURLY, SIX_HOURLY, DAILY, WEEKLY.

Grouping: pass entityId to get a single entity’s series (rows have entityId: null), or omit it to get all entities grouped, with entityId populated per row:

# Message volume per platform connection, daily
query {
  stats(
    sourceType: PLATFORM_CONNECTION
    startDate: "2026-07-07T00:00:00Z"
    endDate: "2026-07-14T00:00:00Z"
    granularity: DAILY
  ) {
    entityId
    timestamp
    count
  }
}

For headline numbers, getStats(timeframe: LAST_30_DAYS) (or ALL_TIME) returns aggregate usersCount, identitiesCount, and messagesCount for the application.

Connection Logs#

Every platform connection writes diagnostic logs: connection usage, webhook receipts, errors. The connection detail page in the console lists these, filterable by level and type:

• logLevel: debug, info, warning, error
• logType: category such as connection_usage, webhook_received, webhook_delivered, webhook_error

Programmatically, the logs query filters by event (eventId / eventIds) rather than by connection, which is the right shape for debugging a specific message:

query {
  logs(eventId: "event-uuid", logLevel: "error", limit: 50) {
    id
    logLevel
    logType
    message
    payload
    createdAt
  }
}

Filtering logs by connection is a console operation, and isn’t available on the API-key developer API.

A spike of `error`-level logs on a connection is usually the earliest signal something broke, often before users notice missing replies. Pair a `stats(sourceType: PLATFORM_CONNECTION)` volume series with an error-log poll for cheap coverage.

Webhook Delivery Health#

Outbound webhook subscriptions (the ones notifying your services) are tracked per delivery: each attempt records status, httpStatus, attemptCount, errorMessage, and deliveredAt, with automatic retries. The subscription detail page in the console surfaces this:

• Recent deliveries: status, HTTP status, attempt count, error message and timestamps for each attempt. Repeated high attempt counts mean your endpoint is flaky or slow.
• Timing stats: average response time (how long your endpoint takes to respond) and average end-to-end latency (from event creation to delivery) over a rolling window.
• Timing history: the same figures bucketed into intervals for trend charts.
• Sparklines: per-subscription daily delivery counts on the webhook list.

Delivery volume is available programmatically on the developer API via stats(sourceType: WEBHOOK); the per-delivery detail above is console-only.

Building an External Monitor#

A minimal monitor needs one API key and a scheduler:

1. Create an API key in the console with read scopes (events:read, logs:read).
2. Poll stats on an interval, e.g. sourceType: EVENT with granularity: FIFTEEN_MINUTE over the last hour.
3. Compare against a baseline and alert on anomalies.

curl -s https://api.outeract.com/ \
  -H "Authorization: Bearer $OUTERACT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "query($from: DateTime!, $to: DateTime!) { stats(sourceType: EVENT, startDate: $from, endDate: $to, granularity: FIFTEEN_MINUTE) { timestamp count } }",
    "variables": { "from": "2026-07-14T08:00:00Z", "to": "2026-07-14T09:00:00Z" }
  }'

Alerting suggestions:

• Inbound silence: stats(sourceType: EVENT_TYPE, entityId: "message.inbound") drops to zero during hours it’s normally busy: a platform webhook likely broke. Follow up with a health check on the connection.
• Per-connection imbalance: grouped PLATFORM_CONNECTION stats show one connection flatlining while others flow.
• Webhook lag: your own subscriber sees event timestamps drifting behind wall-clock time (rising e2e latency) or stops receiving events entirely.
• Simplest heartbeat: since Outeract already pushes events to webhook subscribers, a dead-man’s-switch on your subscription (“alert if no events received in N minutes”) catches most failures with no polling at all.

What the Console Shows#

The console (https://outeract.com/console) assembles the same underlying data into its monitoring surfaces:

• Dashboard activity charts: event volume over time from stats
• Connection health badges: live health check results per connection, with warning/failure tooltips
• Connection detail: usage series and recent logs for that connection
• Webhook subscription detail: delivery list, success/failure status, and response-time / e2e-latency charts
• Sparklines on webhook and connection lists from the per-day delivery stats

The event and stats views have direct developer-API equivalents, so you can reproduce them in your own dashboards; the connection and webhook-delivery views are console-only.

See Also#

• Health Checks - On-demand connection validation
• Events Concept - What the event counts are counting
• GraphQL API - Full schema reference