Skip to main content
StackOne records a log for every action run. You can integrate these logs with your observability stack for centralized monitoring, alerting, and debugging.
This guide is for platform builders who want to integrate StackOne action logs with their existing monitoring infrastructure. For debugging individual failed requests, see Request Log Debugging. To build embedded log dashboards, see Request Log Dashboards.

Integration approaches

Choose the approach that fits your needs:

Query request logs

Logs are read with POST /logs. Filters, ordering and pagination all travel in the JSON body rather than the query string. One row is one action run, and that includes MCP tool calls.

Key fields for monitoring

Filter logs

Filters go in the filters object. Most take an array of strings, so a single value still needs brackets. The rest are scalars, and List Logs gives the type of each.
For pre-aggregated counts rather than raw rows, Logs Stats Aggregate does the grouping server-side and returns far less data.

Grafana direct polling

The simplest approach is to let Grafana poll the StackOne API directly using the Infinity data source.

Setup

  1. Install the Infinity plugin in Grafana
  2. Add a new Infinity data source with these settings:

Example query

Because POST /logs reads its filters from the body, the Infinity panel needs to send a POST with a JSON body rather than a URL with query parameters:
Set Rows/Root to data so Infinity reads the array rather than the pagination envelope.
A panel issues one request, so it renders a single page. Any range holding more rows than page_size gives a partial set with nothing in the panel to say so. Compare total against the row count, narrow the range, or use the sync worker below when the set has to be complete.

Dashboard variables

Create variables for dynamic filtering, and interpolate them into the body as JSON arrays: With multi-value variables, the ${connector:json} format option renders the selection as a JSON array, which is what the filter expects:
This approach is best for dashboards and ad-hoc analysis. For real-time alerting or high-volume ingestion, use the sync worker approach below.

Build a log sync worker

For high-volume ingestion or when you need to transform logs before storing, build a sync worker that polls the StackOne API and forwards logs to your observability platform.
Popular approaches include using Temporal workflows, AWS Lambda with EventBridge schedules, or simple cron jobs. The core pattern is the same: poll for new logs since your last sync, then forward to your platform.

Core pattern

Page forward until you have collected total rows. Bound each run with both start_time and end_time so the result set cannot shift underneath the sweep, and order ascending by event_time so the sequence is deterministic. A run that fails partway is retried whole, because the window is only checkpointed once it completes. Make forwarding idempotent on log_id so the retry does not duplicate rows your platform already holds.

Platform-specific examples


Suggested dashboards

Key metrics to track

Grafana dashboard JSON

These panels query Prometheus, so they assume you already turn action logs into metrics, for example by having the sync worker increment counters as it forwards each row. StackOne does not expose a metrics endpoint, so stackone_action_runs_total and stackone_action_duration_bucket are series you define, not ones you can scrape.

Request Logs API

Full API reference for logs

Dashboard Logs

View logs in the StackOne dashboard

Webhooks

Real-time event notifications