Connections - Struct

Struct integrates with your existing stack to receive alerts, query logs and metrics, and deliver investigation reports where your team already works.

Category	Connections
Work & Collaboration	GitHub (required), Slack, Linear, Asana
Observability Platforms	Sentry, Datadog, Grafana, Prometheus, Loki, SumoLogic, Render
Cloud Log Providers	AWS CloudWatch, Azure Monitor, Google Cloud Logging
Container & Orchestration	Kubernetes

All observability and cloud log integrations are read-only. Struct never modifies your monitoring configuration, log groups, or workspaces.

Work & Collaboration

Integration	Required	Purpose
GitHub	Yes	Codebase context and PR creation
Slack	No	Receive investigations, trigger on-demand queries
Linear	No	Trigger from issues, track progress
Asana	No	Trigger from tasks (requires configuration)

GitHub

Required. GitHub is how Struct accesses your codebase during investigations and creates pull requests.

Go to Connections

Click Connect next to GitHub

Install the Struct GitHub App

Select which repositories to enable

With GitHub connected, Struct can:

Cross-reference errors with recent commits and deployments
Run deployment audits from GitHub Deployments (or a webhook if your pipeline does not create them)
Search your codebase for relevant code paths
Create branches and pull requests when a fix is approved

Start with a single repository to test the workflow before expanding access.

Slack

Connect Slack to receive investigation reports and trigger on-demand investigations.

Go to Connections

Click Connect next to Slack

Authorize the Struct app in your workspace

Invite @Struct to channels where alerts are posted

Triggering Investigations

Mention Struct in any channel where it’s been invited:

@Struct investigate high error rate on the payments API

Struct responds in-thread with a structured investigation report.

You can ask follow-up questions directly in the thread—Struct maintains full context throughout the conversation.

Auto-Investigation

Struct can also automatically investigate messages in your configured investigation channels. Configure keyword filters to control which alerts trigger investigations, or let AI classification decide. See Auto-Investigations for setup details.

Linear

Connect Linear to trigger investigations from issues and receive updates as comments.

Go to Connections

Click Connect next to Linear

Authorize and select teams to monitor

Assign an issue to Struct or @tag it in a comment to trigger an investigation. Struct posts its findings as a comment on the issue.

Auto-Investigation

Enable auto-investigation to have Struct automatically investigate new issues created in your default team. Configure keyword filters to focus on specific issue types. See Auto-Investigations for setup details.

Asana

Connect Asana to trigger investigations from tasks.

Go to Connections

Click Connect next to Asana

Authorize and select projects to monitor

Automatic investigation triggers are not enabled by default. Enable auto-investigation and configure keyword filters in Connections → Asana → Manage.

See Auto-Investigations for setup details.

Observability Platforms

Struct queries your observability platforms during investigations to pull error details, metrics, traces, and alert context. The more sources connected, the richer the investigation.

Platform	What Struct Pulls
Sentry	Stack traces, breadcrumbs, error frequency, affected users
Datadog	Metrics, monitors, APM traces, event context
Grafana	Dashboard data, alert rules, annotations
Prometheus	Metrics, alerting rules, time-series data
Loki	Log streams, label-based log queries
SumoLogic	Log analytics, search results
Render	Service logs, deploy events
Snowflake	Telemetry (event tables), query history, read-only SQL

To connect an observability platform, go to Connections and click Connect next to the platform.

Sentry

Recommended. Sentry is one of the most impactful integrations—it gives Struct direct access to error details and stack traces.

Go to Connections

Click Connect next to Sentry

Follow the instructions to complete setup

What Struct uses from Sentry

Stack traces — Pinpoints the exact code path that threw the error
Breadcrumbs — Reconstructs the sequence of events leading to the error
Error frequency — Determines if this is a new issue or a recurring pattern
Affected users — Assesses impact scope

Example

When a Sentry alert fires, Struct automatically:

Pulls the full stack trace and breadcrumbs
Cross-references the failing code with recent commits
Checks if this error pattern has appeared in previous investigations
Delivers a root cause report to Slack

Datadog

Go to Connections

Click Connect next to Datadog

Follow the instructions to complete setup

Required application key scopes

Datadog enforces read permissions on the application key’s role, not the API key. The role attached to the application key you provide must grant all of the following scopes, or Struct will receive 403 Forbidden from the corresponding endpoints:

Scope	Used for
`logs_read_data`	Searching and reading logs
`logs_read_index`	Searching log indexes
`monitors_read`	Reading monitors and alert state
`dashboards_read`	Listing and reading dashboards
`apm_read`	Searching and listing APM traces
`metrics_read`	Searching and reading metrics
`timeseries_query`	Querying metric timeseries values

What Struct uses from Datadog

Metrics — CPU, memory, latency, error rates, and custom metrics
APM traces — Distributed traces across services; fetch a full trace by trace ID to inspect span timing and pinpoint the slow or failing service
Monitors — Alert context and monitor history
Events — Deployment events, configuration changes

You can use Struct to query Datadog metrics in natural language. For example: “Show me p99 latency for the checkout service over the last 2 hours.”

Grafana

Go to Connections

Click Connect next to Grafana

Follow the instructions to complete setup

What Struct uses from Grafana

Dashboard data — Queries panels for relevant metrics
Alert rules — Understands what thresholds triggered
Annotations — Correlates deployments and incidents with metric changes

Prometheus

Go to Connections

Click Connect next to Prometheus

Follow the instructions to complete setup

What Struct uses from Prometheus

Metrics — Queries PromQL-compatible metrics during investigations
Alerting rules — Reads active and pending alerts for context
Time-series data — Analyzes trends around the time of the incident

Loki

Go to Connections

Click Connect next to Loki

Follow the instructions to complete setup

What Struct uses from Loki

Log streams — Queries logs by labels, service, and time range
Log context — Pulls surrounding log lines for errors

Example query Struct might run

{service="api-gateway"} |= "error" | json | status >= 500

If you use Grafana with Loki as a data source, connect both for the richest investigation context.

SumoLogic

Go to Connections

Click Connect next to SumoLogic

Follow the instructions to complete setup

What Struct uses from SumoLogic

Log search — Runs targeted searches across your log data
Analytics — Aggregates and patterns from log analytics

Render

Go to Connections

Click Connect next to Render

Follow the instructions to complete setup

What Struct uses from Render

Service logs — Pulls application logs from your Render services
Deploy events — Correlates errors with recent deployments

Snowflake

Struct connects to Snowflake with key-pair authentication: a fresh RSA key pair is generated for each connection, you set the public key on a dedicated read-only service user, and Struct signs a short-lived JWT per request. There is no password or token to rotate or renew, and no network policy is required.

Go to Connections and click Connect next to Snowflake

Choose a service user name (default: STRUCT_READER)

Run the setup command

Copy the generated SQL into a Snowsight worksheet and run it as an admin (e.g. ACCOUNTADMIN). It creates the service user (if it doesn’t exist), sets the generated public key on it, and grants a read-only role.

Enter your account identifier and click Connect

From your Snowsight URL app.snowflake.com/<org>/<account>/…, join the two path segments with a dash (e.g. app.snowflake.com/mkzwlrt/qx41832 → mkzwlrt-qx41832).

The warehouse, default database, and event table are detected automatically from the account — no manual configuration needed.

What Struct uses from Snowflake

Telemetry (event tables) — Logs, traces, and metrics emitted by stored procedures, UDFs, Snowpark code, tasks, and dynamic tables
Query history — Failed loads, pipeline errors, and slow queries from the last 7 days, with error codes and timing breakdowns
Read-only SQL — Answers data questions (counts, lookups, aggregations) against tables you’ve granted access to

Access is read-only

The setup command grants Struct read access only: the SNOWFLAKE.EVENTS_VIEWER application role for telemetry, USAGE on one warehouse to run queries, and SELECT across your databases. Struct can never write to your account. The database grants are applied by a loop over your current standard databases (shared databases and Native Apps are skipped). FUTURE grants cover new tables, views, and schemas created inside those databases automatically — but if you create a brand-new database later, re-run the EXECUTE IMMEDIATE block from the setup command to include it (Snowflake has no account-wide grant).

Prefer a narrower scope? Skip the EXECUTE IMMEDIATE block and grant only specific databases instead:

GRANT USAGE ON DATABASE MY_DB TO ROLE STRUCT_READER_ROLE;
GRANT USAGE ON ALL SCHEMAS IN DATABASE MY_DB TO ROLE STRUCT_READER_ROLE;
GRANT SELECT ON ALL TABLES IN DATABASE MY_DB TO ROLE STRUCT_READER_ROLE;
GRANT SELECT ON ALL VIEWS IN DATABASE MY_DB TO ROLE STRUCT_READER_ROLE;

To revoke access at any time, run:

ALTER USER STRUCT_READER UNSET RSA_PUBLIC_KEY;

IP allowlisting (optional)

You can restrict where the Struct service user is allowed to connect from with a Snowflake network policy:

CREATE NETWORK POLICY struct_policy ALLOWED_IP_LIST = ('<struct-egress-ip>');
ALTER USER STRUCT_READER SET NETWORK_POLICY = struct_policy;

Contact support for Struct’s current egress IP addresses. Key-pair authentication works with or without a network policy — this is optional hardening, not a requirement.

Cloud Log Providers

Struct queries your cloud logs in real time during investigations—pulling relevant log entries, filtering by time range, and correlating log patterns with errors and alerts.

Provider	Status
AWS CloudWatch	Available
Azure Monitor / Log Analytics	Available
Google Cloud Logging	Available

To connect a cloud log provider, go to Connections and follow the setup instructions for your provider.

AWS CloudWatch

Go to Connections

Click Connect next to AWS CloudWatch

Follow the instructions to complete setup

What Struct queries

Log groups — Application and service logs
Log streams — Filtered by time range and keywords
CloudWatch Insights — Structured queries across log groups

Example

During an investigation into a Lambda timeout, Struct might query:

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 50

Grant access to specific log groups rather than all logs if you want to limit scope.

Azure Monitor

Go to Connections

Click Connect next to Azure Monitor

Follow the instructions to complete setup

What Struct queries

Log Analytics workspaces — Application logs, custom logs, diagnostic logs
KQL queries — Structured queries across Azure log data
Resource logs — Logs from Azure services (App Service, Functions, AKS, etc.)

Example

Investigating a spike in Azure App Service errors, Struct might run:

AppServiceHTTPLogs
| where ScStatus >= 500
| where TimeGenerated > ago(1h)
| summarize count() by CsUriStem, bin(TimeGenerated, 5m)
| order by count_ desc

Google Cloud Logging

Go to Connections

Click Connect next to Google Cloud Logging

Follow the instructions to complete setup

What Struct queries

Cloud Logging entries — Application logs, request logs, system logs
Log-based queries — Filtered by resource, severity, and time
GKE and Cloud Run logs — Container and serverless application logs

Example

Investigating a Cloud Run service crash, Struct might query:

resource.type="cloud_run_revision"
severity>=ERROR
timestamp>="2024-01-15T10:00:00Z"

The more log sources Struct can access, the faster and more accurate root cause analysis becomes. Connect all relevant providers.

How Struct Uses Cloud Logs

During every investigation, Struct:

Identifies relevant log sources based on the alert and affected services
Builds targeted queries to pull error logs, warnings, and contextual entries
Correlates log patterns with metrics, traces, and code changes
Highlights key log lines in the investigation report with timestamps and context

Ensure your cloud provider credentials have sufficient permissions to read logs. Investigations will be less accurate without log access.

Container & Orchestration

Struct can query your Kubernetes clusters directly to pull pod logs, events, and resource status during investigations.

Platform	What Struct Pulls
Kubernetes	Pod logs, events, namespace resources

Kubernetes

Go to Connections

Click Connect next to Kubernetes

Choose ServiceAccount Token (recommended) or kubeconfig YAML

Follow the setup instructions below

What Struct uses from Kubernetes

Pod logs — Pulls application logs directly from pods
Events — Surfaces Kubernetes events (restarts, scheduling issues, OOM kills)
Namespace resources — Lists pods and their status

ServiceAccount Token Setup (Recommended)

This approach uses a secret-bound token that works with all Kubernetes clusters, including GKE, GKE Autopilot, EKS, and AKS:

# Create the ServiceAccount
kubectl create serviceaccount log-reader -n default

# Create RBAC permissions
kubectl apply -f - <<'EOF'
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: log-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log", "namespaces", "events"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: log-reader-binding
subjects:
  - kind: ServiceAccount
    name: log-reader
    namespace: default
roleRef:
  kind: ClusterRole
  name: log-reader
  apiGroup: rbac.authorization.k8s.io
EOF

# Create a Secret-bound token (does not expire)
kubectl apply -f - <<'EOF'
apiVersion: v1
kind: Secret
metadata:
  name: log-reader-token
  namespace: default
  annotations:
    kubernetes.io/service-account.name: log-reader
type: kubernetes.io/service-account-token
EOF

# Retrieve the token
kubectl get secret log-reader-token -n default -o jsonpath='{.data.token}' | base64 -d

Secret-bound tokens are long-lived and don’t require rotation. This approach works on all clusters including GKE Autopilot, which enforces a 48-hour max on kubectl create token.

Getting the API Server URL

Run this command to find your cluster’s API server URL:

kubectl cluster-info | grep "control plane"

CA Certificate (Optional)

If your cluster uses a self-signed CA, you’ll need to provide the CA certificate:

kubectl config view --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' | base64 -d

Need an integration we don’t support yet? New integrations can be built in days — reach out at [email protected]. Jira, ClickUp, and PagerDuty integrations are coming soon.

​Work & Collaboration

​GitHub

​Slack

​Triggering Investigations

​Auto-Investigation

​Linear

​Auto-Investigation

​Asana

​Observability Platforms

​Sentry

​What Struct uses from Sentry

​Example

​Datadog

​Required application key scopes

​What Struct uses from Datadog

​Grafana

​What Struct uses from Grafana

​Prometheus

​What Struct uses from Prometheus

​Loki

​What Struct uses from Loki

​Example query Struct might run

​SumoLogic

​What Struct uses from SumoLogic

​Render

​What Struct uses from Render

​Snowflake

​What Struct uses from Snowflake

​Access is read-only

​IP allowlisting (optional)

​Cloud Log Providers

​AWS CloudWatch

​What Struct queries

​Example

​Azure Monitor

​What Struct queries

​Example

​Google Cloud Logging

​What Struct queries

​Example

​How Struct Uses Cloud Logs

​Container & Orchestration

​Kubernetes

​What Struct uses from Kubernetes

​ServiceAccount Token Setup (Recommended)

​Getting the API Server URL

​CA Certificate (Optional)

Work & Collaboration

GitHub

Slack

Triggering Investigations

Auto-Investigation

Linear

Auto-Investigation

Asana

Observability Platforms

Sentry

What Struct uses from Sentry

Example

Datadog

Required application key scopes

What Struct uses from Datadog

Grafana

What Struct uses from Grafana

Prometheus

What Struct uses from Prometheus

Loki

What Struct uses from Loki

Example query Struct might run

SumoLogic

What Struct uses from SumoLogic

Render

What Struct uses from Render

Snowflake

What Struct uses from Snowflake

Access is read-only

IP allowlisting (optional)

Cloud Log Providers

AWS CloudWatch

What Struct queries

Example

Azure Monitor

What Struct queries

Example

Google Cloud Logging

What Struct queries

Example

How Struct Uses Cloud Logs

Container & Orchestration

Kubernetes

What Struct uses from Kubernetes

ServiceAccount Token Setup (Recommended)

Getting the API Server URL

CA Certificate (Optional)