How to Send a Weekly Reliability Report Email from MySQL Incident Data

Build a Spojit workflow that runs every week, queries your incident and uptime tables in MySQL, computes mean time to recovery and incident counts with the math connector, drafts a plain-language reliability narrative in Agent mode, and emails the combined report to leadership.

What This Integration Does

Most teams already record incidents and uptime in a database, but turning that raw data into a digestible weekly summary is a manual chore that someone has to remember to do every Monday. This workflow removes that chore. On a fixed weekly schedule, Spojit pulls last week's incident records and uptime figures straight from MySQL, calculates the headline reliability metrics for you, asks Miraxa to translate the numbers into a short narrative that non-engineers can act on, and sends the finished report to your leadership distribution list. The result is a consistent, on-time reliability update that nobody has to assemble by hand.

The workflow is started by a Schedule trigger on a weekly cron, so it runs unattended at the same time each week with no input from you. Each run queries MySQL for the previous seven days, derives metrics such as incident count and mean time to recovery, produces a written summary, and ends by sending one email. It does not change any data in your database (the queries are read-only SELECT statements), so re-running it is always safe: a manual re-run simply produces a fresh copy of the same report for that period and sends another email.

Prerequisites

A MySQL connection added in Spojit under Connections, pointing at the database that holds your incident and uptime history.
Tables you can query for incidents and uptime. This tutorial assumes an incidents table with columns such as opened_at, resolved_at, and severity, and an uptime_daily table with day and uptime_pct. Adjust the queries to match your real schema.
The leadership recipients added to your org email allowlist under Settings -> General -> Email recipients, since the built-in Send Email node only delivers to allowlisted addresses.
A rough idea of the timezone the report period should be anchored to (for example your operations region) so the weekly window lines up with how your team thinks about "last week".

Step 1: Start the workflow on a weekly schedule

Create a new workflow and set its Trigger node type to Schedule. Add a 5-field Unix cron expression and an IANA timezone. To run every Monday at 07:00, use:

0 7 * * 1
Australia/Sydney

The Schedule trigger fires unattended and exposes {{ scheduledAt }} as its output, which is the timestamp of the run. A single trigger can hold more than one schedule if you later want, say, an extra mid-week run. Everything downstream reads its data from MySQL rather than from the trigger, so the trigger only needs to decide when the report runs.

Step 2: Query incident data from MySQL

Add a Connector node on the mysql connector in Direct mode and choose the execute-query tool. Direct mode is right here because you want a deterministic, single query with no AI cost. Put your read-only SQL in the query field. This statement returns last week's incident count and the average time to recovery in minutes:

SELECT
  COUNT(*) AS incident_count,
  SUM(severity = 'critical') AS critical_count,
  AVG(TIMESTAMPDIFF(MINUTE, opened_at, resolved_at)) AS avg_mttr_minutes
FROM incidents
WHERE resolved_at >= NOW() - INTERVAL 7 DAY;

If you want to parameterize values instead of inlining them, use ? placeholders in query and supply the values in the params array. Set the node's output variable name (for example incidentStats) so later steps can read fields like {{ incidentStats.rows.0.incident_count }} and {{ incidentStats.rows.0.avg_mttr_minutes }}.

Step 3: Query uptime data from MySQL

Add a second Connector node on the mysql connector in Direct mode, again using execute-query, to pull the uptime figures for the same window. For example:

SELECT
  ROUND(AVG(uptime_pct), 3) AS avg_uptime_pct,
  MIN(uptime_pct) AS worst_day_pct,
  COUNT(*) AS days_measured
FROM uptime_daily
WHERE day >= CURDATE() - INTERVAL 7 DAY;

Name the output (for example uptimeStats). You now have two result sets: incident counts plus average recovery time, and the week's average and worst-day uptime. Keeping the two queries in separate nodes makes each one easy to read in the execution log when you are debugging.

Step 4: Compute the reliability metrics with the math connector

Add a Connector node on the math connector in Direct mode and use the calculate tool to turn the raw figures into the numbers leadership cares about. The database already gave you the average recovery time, so use calculate to derive figures that depend on combining values, such as downtime budget consumed. For example, to express the week's uptime as minutes of downtime out of a 10,080-minute week, set the expression to reference your variables:

(100 - {{ uptimeStats.rows.0.avg_uptime_pct }}) / 100 * 10080

Name the output (for example downtimeMinutes). You can add more math nodes for any other derived figure you want in the report, for instance using round to clean up {{ incidentStats.rows.0.avg_mttr_minutes }} for display, or percentage to show critical incidents as a share of the total. Keep these calculations in Direct mode so they stay deterministic and free of AI cost.

Step 5: Draft the reliability narrative in Agent mode

Add a Connector node and switch it to Agent mode. Agent mode lets Miraxa, the intelligent layer across your automation, turn your metrics into a short, plain-language summary that a non-engineer can read. Write a prompt that hands it the figures and tells it the audience and tone:

You are writing the weekly reliability summary for company leadership.
Use plain language, no jargon, 4 to 6 sentences.
Data for the last 7 days:
- Incidents: {{ incidentStats.rows.0.incident_count }} ({{ incidentStats.rows.0.critical_count }} critical)
- Mean time to recovery: {{ incidentStats.rows.0.avg_mttr_minutes }} minutes
- Average uptime: {{ uptimeStats.rows.0.avg_uptime_pct }}%
- Worst day uptime: {{ uptimeStats.rows.0.worst_day_pct }}%
- Estimated downtime: {{ downtimeMinutes.result }} minutes
Call out whether reliability improved or worsened and what to watch next week.

Name the output (for example narrative) so the email step can include {{ narrative.content }}. If you want the summary in a fixed structure (for example separate headline and detail fields), define a Response Schema on this node to force structured JSON output. Agent mode costs AI credits, so this is the one node in the workflow that does.

Step 6: Email the combined report to leadership

Add a Send Email node to deliver the report from Spojit's built-in mail service (no connection required). Fill in the fields:

Recipients: your leadership distribution list, comma-separated, for example leadership@yourcompany.com. Every address must be on the org email allowlist.
Subject: templated, for example Weekly Reliability Report - {{ scheduledAt }}.
Body: plain text that combines the hard numbers and the narrative, for example:

Reliability summary for the last 7 days

Incidents: {{ incidentStats.rows.0.incident_count }} ({{ incidentStats.rows.0.critical_count }} critical)
Mean time to recovery: {{ incidentStats.rows.0.avg_mttr_minutes }} min
Average uptime: {{ uptimeStats.rows.0.avg_uptime_pct }}%
Worst day: {{ uptimeStats.rows.0.worst_day_pct }}%
Estimated downtime: {{ downtimeMinutes.result }} min

{{ narrative.content }}

Set If sending fails to Fail the workflow so a missed report shows up as a failed run you can investigate, rather than passing silently. The Send Email node counts toward your monthly email allowance. To send from your own domain instead of Spojit's built-in service, swap this node for a Connector node on the resend or smtp connector and use its send-email tool.

Tips

Anchor the report window to the same timezone as your Schedule trigger so the SQL "last 7 days" and the trigger time describe the same period.
Use the math connector's round and percentage tools to format figures for humans, so leadership sees 99.95% rather than a long decimal pulled straight from the database.
Keep the two MySQL queries narrow and read-only. The fewer columns you return, the easier the execution log is to scan when a number looks wrong.
Ask Miraxa to scaffold the canvas for you with a prompt like "Add a Schedule trigger, two MySQL Connector nodes in Direct mode, a math Connector node, an Agent mode node, and a Send Email node, connected in sequence", then fine-tune each node in the properties panel.

Common Pitfalls

If avg_mttr_minutes comes back empty, you likely had no resolved incidents in the window. Handle the empty case in your prompt and email body so the report still reads cleanly during a quiet week.
Schedule triggers run in the timezone you set, not the server's. A cron written for UTC will fire at the wrong local hour. Double-check the IANA timezone string.
If the Send Email step reports a rejected recipient, the address is not on the org allowlist. Add it under Settings -> General -> Email recipients before the next run.
Schema drift breaks queries silently: if someone renames resolved_at, the query fails. Pin your column names and review them when the team changes the database.

Testing

Before turning the schedule on, validate the whole chain on a small scope. Temporarily narrow the MySQL queries to INTERVAL 1 DAY and run the workflow with the Run button, then open the execution log and confirm each node's output: the two query results, the math result, and the narrative. Point the Send Email recipients at your own allowlisted address first so you can read the rendered report end to end. Once the email looks right, restore the 7-day window, set the recipients to the leadership list, and let the Schedule trigger take over.