How to Run an AI Log Analysis Digest from a REST Log API

Pull recent log entries from your logging platform's REST API on a nightly schedule, let an Agent-mode Connector node surface the top error patterns and anomalies with a forced JSON output, and post a prioritized digest to Slack.

What This Integration Does

Most teams have a logging platform that records far more than anyone reads. Errors spike, a new exception class appears, or a downstream dependency starts timing out, and nobody notices until a customer does. This Spojit workflow reads the last 24 hours of log entries straight from your logging platform's REST API, hands them to an Agent-mode Connector node to group and rank what actually matters, and drops a short, ranked digest into a Slack channel every morning. Your on-call engineer opens Slack and sees the top five recurring error patterns, any anomalies versus a normal night, and a one-line recommendation for each, instead of scrolling raw log lines.

The workflow runs on a Schedule trigger (a nightly cron), so there is nothing to click. Each run fetches a fresh window of logs with the http connector, reshapes them with a Transform node, asks a Connector node in Agent mode to analyze them against a fixed Response Schema, and sends the result to Slack. Runs are stateless and independent: each night starts clean from the log API, so a missed or failed run simply skips that digest and the next night catches the current window. Nothing is written back to your logging platform, and re-running the workflow manually just produces another digest for the same window.

Prerequisites

A logging platform that exposes a REST API for querying recent log entries (for example a search or events endpoint), plus an API key or token you can send in an Authorization header.
A Slack connection added in Spojit under Connections, with permission to post to the target channel. Have the channel ID ready (for example C0123456789).
The http connector, which is built in and needs no separate connection.
A workspace plan that includes AI credits, since Agent mode runs an AI agent to analyze the logs.
Know your reporting timezone so the schedule fires at the hour you expect.

Step 1: Start with a Schedule trigger

Create a new workflow in the Spojit designer and set the Trigger node type to Schedule. Add a 5-field Unix cron expression and an IANA timezone. For a digest at 7am every day, use:

0 7 * * *
Australia/Sydney

The Schedule trigger outputs { scheduledAt }, which you can reference downstream as {{ scheduledAt }} when you want to stamp the digest with the run time. A single trigger can hold multiple schedules if you want both a morning and an evening digest.

Step 2: Compute the time window for the query

Add a Connector node in Direct mode on the date connector and use subtract to compute a timestamp 24 hours before {{ scheduledAt }}. Store it in an output variable such as windowStart. This gives you a clean ISO start bound to pass to your log API so each run only pulls the last day, rather than re-reading everything. If your log API accepts a relative range (like now-24h) instead, you can skip this step and inline that value in the next request.

Step 3: Pull recent log entries with the http connector

Add a Connector node in Direct mode on the http connector and pick the http-post tool (use http-get instead if your platform queries via URL parameters). Point the url at your logging platform's search endpoint, for example https://api.yourlogs.com/v1/search. Add your token under headers as Authorization, and send the query and time window in the body:

{
  "from": "{{ windowStart }}",
  "to": "{{ scheduledAt }}",
  "level": ["error", "warn"],
  "limit": 500
}

This is the same pattern described in the tutorial on connecting to any REST API with HTTP Requests: there is no named connector for your logging platform, so you reach it honestly through http. Store the response in an output variable such as logResult. Keep limit bounded so a single run does not pull tens of thousands of lines into the next step.

Step 4: Reshape the logs with a Transform node

Raw log API responses carry a lot of fields you do not need for analysis, and trimming them keeps the AI step focused and cheaper. Add a Transform node that reads {{ logResult }} and produces a compact array, keeping only what matters for pattern detection, such as timestamp, level, service, message, and any error code or trace identifier. Output something like:

{
  "windowStart": "{{ windowStart }}",
  "windowEnd": "{{ scheduledAt }}",
  "entries": [
    { "timestamp": "...", "level": "error", "service": "checkout", "message": "..." }
  ]
}

Store the result in a variable such as logsForAnalysis. If your platform returns thousands of entries, also collapse near-identical messages here (or cap the array length) so you send the agent a representative sample rather than every line.

Step 5: Analyze the logs with a Connector node in Agent mode

Add a Connector node and switch it to Agent mode. This is where the agent reads the log sample and decides what is worth reporting. Reference the trimmed logs in the prompt and ask for grouped, ranked findings:

You are reviewing application logs from {{ logsForAnalysis.windowStart }}
to {{ logsForAnalysis.windowEnd }}.
Logs: {{ logsForAnalysis.entries }}

Identify the top recurring error patterns and any anomalies
(new error types, unusual spikes, services that look unhealthy).
Rank findings by severity. For each, give a short title, a count
estimate, the affected service, and a one-line recommendation.

To make the output reliable to post and parse, fill in the Response Schema so the agent must return structured JSON instead of prose:

{
  "type": "object",
  "properties": {
    "summary": { "type": "string" },
    "findings": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "title": { "type": "string" },
          "severity": { "type": "string", "enum": ["high", "medium", "low"] },
          "service": { "type": "string" },
          "count": { "type": "integer" },
          "recommendation": { "type": "string" }
        },
        "required": ["title", "severity", "recommendation"]
      }
    },
    "anomalies": { "type": "array", "items": { "type": "string" } }
  },
  "required": ["summary", "findings"]
}

Store the structured result in an output variable such as analysis. The Response Schema is what makes this dependable night after night: you always get analysis.findings as a clean array you can format, rather than free text you have to scrape. For more on this pattern, see the guide on using Connector nodes in Agent mode.

Step 6: Format and deliver the digest to Slack

Add a final Connector node in Direct mode on the slack connector and pick the send-message tool. Set channel to your destination channel ID (for example C0123456789) and build text from the structured analysis. A simple, readable digest:

:rotating_light: Nightly Log Digest ({{ scheduledAt }})
{{ analysis.summary }}

Top findings:
{{ analysis.findings }}

Anomalies:
{{ analysis.anomalies }}

For richer layout you can pass Block Kit blocks instead of plain text, and reply into a daily thread by setting thread_ts. Because analysis.findings is already ranked by severity from the Response Schema, the high-severity items read first. If you want the digest to skip quiet nights, add a Condition node before this step that only continues when {{ analysis.findings }} is non-empty.

Tips

Trim aggressively in the Transform node. Fewer, deduplicated log lines mean lower AI cost in Agent mode and sharper findings, since the agent is not distracted by noise.
Pin the schedule timezone explicitly. A cron of 0 7 * * * means 7am in whatever IANA zone you set, so a US team and an Australian team need different zones for the same local hour.
Send a digest even on calm nights by including the summary line, so the channel confirms the workflow ran rather than going silent and leaving people unsure.
Use the Slack channel ID (not the channel name) in send-message; you can look it up in Slack or with the slack connector's list-channels tool.

Common Pitfalls

Unbounded log queries. Without a limit and a time window, your log API can return enormous payloads that slow the run and inflate AI cost. Always bound both the range and the row count.
Free-text AI output. If you skip the Response Schema, the agent may return prose that varies run to run and breaks your Slack formatting. The schema forces a stable shape every night.
Timezone drift on the schedule. A missing or wrong IANA zone makes the digest fire at an unexpected hour; confirm it against your reporting timezone.
Token in the wrong place. Your logging platform's token belongs in the http-post headers as Authorization, not in the body. A 401 from the API usually means the header is missing or malformed.

Testing

Before turning on the nightly schedule, validate the chain on a small scope. Temporarily narrow the log query to a short window (for example the last hour) and a small limit so the http step returns a handful of entries, then run the workflow with the Run button. Open the execution log to confirm logResult came back, that the Transform node produced your trimmed logsForAnalysis, and that analysis matches the Response Schema with a populated findings array. Point send-message at a private test channel first and check the digest reads cleanly, then widen the window back to 24 hours and switch the destination to the real channel. If a step fails, ask Miraxa "Why did my last run fail?" from the chat surface for a quick read on the error.