Internal Comms & Meetings

How to run an async standup as Small IT and ITOps Teams

Internal Comms & MeetingsFor Small IT and ITOps Teams3 apps12 steps~24 min to set up

Your 2-person IT team runs standups over Slack, email threads, or a 15-minute call that half the team misses because someone is mid-ticket. The result: blockers sit unnoticed until Friday, the same Jira ticket gets touched twice by different people, and nobody has a clear record of what was resolved yesterday versus what's still open. You're context-switching between Jira Service Management, Slack, PagerDuty alerts, and a Notion runbook that hasn't been updated since Q3. There's no time to write a standup summary and no one to read it anyway. The async standup exists in theory; in practice it's a Slack message that gets buried under a laptop-slow ticket within 20 minutes.

Build this on Starch → See the apps used

Internal Comms & MeetingsFor Small IT and ITOps Teams3 apps12 steps~24 min to set up

Outcome

What you'll set up

A daily async standup that pulls open Jira tickets, PagerDuty incidents, and AWS cost anomalies into a single morning digest — no meeting required

Automatic action-item capture from standup threads and incident postmortems, assigned to the right person with due dates, tracked in one place

A searchable archive of every standup update and decision so when someone asks 'didn't we close that ticket last week?' you can find the exact answer in under a minute

The Starch recipe

Apps, data, and prompts

The combination of Starch apps, the data sources they pull from, and the prompts you use to drive them.

Apps used

Project Management Task Manager Meeting Notes

Data sources & config

Connect Jira and PagerDuty from Starch's integration catalog — the agent queries them live each morning when the standup automation runs. Starch connects directly to AWS so cost anomalies are pulled on demand. Connect Slack from Starch's integration catalog to post the digest. Starch syncs your Notion data on a schedule so weekly summaries are written directly to your runbook database. Task Manager and Project Management live inside Starch — no additional connection needed.

Prompts to copy

Every weekday at 8:30 AM, pull all Jira tickets updated in the last 24 hours for the IT project, any PagerDuty incidents that opened or closed overnight, and any AWS Cost Explorer anomalies flagged since yesterday. Format it as an async standup digest with three sections: What was resolved, What's still open with owner and priority, and Blockers that need a decision today. Post it to the #it-ops Slack channel.

After each async standup digest is posted, extract any action items mentioned in the thread replies, create tasks in the Task Manager with the assignee and due date, and send me a summary of new tasks created.

Every Friday at 4 PM, generate a weekly IT ops summary: total tickets closed, average resolution time from Jira, any recurring incident patterns from PagerDuty this week, and open blockers carried into next week. Archive it in Notion under the IT Weekly Log database.

Run these in Starch → or paste them into your favorite agent

Walkthrough

Step-by-step

1 Connect Jira from Starch's integration catalog. The agent will query your IT project's open and recently updated tickets live each time the standup automation runs — no manual export needed.

2 Connect PagerDuty from Starch's integration catalog so overnight incidents and on-call alerts are included in the morning digest automatically.

3 Connect AWS from Starch's integration catalog. Cost Explorer anomalies and any CloudWatch alerts relevant to your team are pulled on demand and included in the standup block.

4 Connect Slack from Starch's integration catalog so the finished digest posts directly to #it-ops at 8:30 AM every weekday without anyone having to trigger it.

5 Connect Notion — Starch syncs your Notion data on a schedule — and point it at your IT runbook database so Friday summaries are written there automatically.

6 Install the Task Manager app from Starch's App Store. Describe the action-item extraction rule: after each digest is posted, Starch reads thread replies and creates tasks for anything that looks like a commitment or blocker.

7 Install the Project Management app and describe your IT ops board: 'Create a board with columns for Incoming, In Progress, Blocked, and Resolved. Pull open Jira tickets as cards and sync status changes back daily.' This becomes your single IT ops surface inside Starch.

8 Install Meeting Notes for the occasional call you can't avoid — incident postmortems, vendor reviews, onboarding syncs. Meeting Notes transcribes, summarizes, and extracts action items that feed back into the Task Manager automatically.

9 Set the weekly Friday summary automation. Describe it: 'Every Friday at 4 PM, query Jira for tickets closed this week, PagerDuty for incidents opened and resolved, and write a structured summary to the IT Weekly Log database in Notion.'

10 Run the first digest manually to validate the output. Adjust the prompt — 'Only include tickets assigned to the IT project, exclude tickets in the Done column for more than 48 hours' — until the digest matches what you'd actually read.

11 After two weeks, ask Starch: 'Which Jira ticket types have the longest average open time this month?' Use the answer to identify recurring work that should become a runbook template or automation rather than a recurring ticket.

12 Optionally publish your standup automation as a shared app in Starch's marketplace so other small IT teams can install and fork your exact setup.

See this running on Starch

Connect your tools, describe what you want, and the agent builds it. Closed beta is free.

Try it on Starch →

Worked example

Tuesday standup digest — April 15, 2026

Sample numbers from a real run

Jira tickets resolved (last 24h)	4
Jira tickets still open (IT project)	11
PagerDuty incidents opened overnight	2
PagerDuty incidents auto-resolved	1
AWS Cost Explorer anomaly flagged	1
Action items extracted from thread	3

At 8:30 AM on April 15, Starch queries Jira and finds 4 tickets closed since Monday — two laptop provisioning requests for new hires, one Okta SSO config fix, one Zoom license reclaim completed. 11 tickets remain open; 3 are marked P1 including a broken VPN client affecting 12 employees in the London office, owner: Marcus, no update in 36 hours — flagged as a blocker in the digest. PagerDuty shows 2 overnight incidents: a disk-space alert on the file server that auto-resolved at 2:14 AM, and a failed Datadog synthetic monitor on the internal HR portal that is still open. AWS Cost Explorer flagged a $340 spike in EC2 spend in us-east-1 that doesn't match any scheduled job. The digest posts to #it-ops at 8:30 AM. Marcus replies: 'VPN fix requires a new config push via Jamf — I'll do it by noon.' Starch reads the reply, creates a Task Manager item: 'VPN config push via Jamf — Marcus — due 12:00 PM today — P1,' and sends a confirmation message. By end of day the digest archive in Notion has a complete record: what was open, what was said, what was committed, and who owns it.

Measurement

How you'll know it's working

Mean time to acknowledge (MTTA) on P1 Jira tickets — are blockers getting picked up within the shift or sitting overnight?

Standup participation rate — what percentage of async digest threads get at least one status reply from each IT team member?

Action items extracted vs. action items completed by end of week — tracks whether async commitments actually close

Recurring ticket type frequency — how many tickets this month are the same category (e.g., 'laptop slow', 'SSO access request') that should be automated or runbooked instead?

AWS cost anomaly response time — minutes from digest post to finance notification when a spend spike is flagged

Comparison

What this replaces

The other ways teams handle this today, and how the Starch version compares.

Slack standup bots (Geekbot, Standuply)

Collect typed responses well but have no awareness of your actual Jira queue, PagerDuty incidents, or AWS anomalies — you're still writing context manually every morning.

Jira + Confluence weekly status reports

Jira has the ticket data but generating a readable digest from it requires either a manual export or a reporting plugin that someone has to configure and maintain; Confluence pages go stale.

Linear + Notion manual standup doc

Works for pure software teams but doesn't know about PagerDuty, AWS, or Okta — an IT ops standup without infrastructure visibility is missing half the picture.

Microsoft Teams daily channel post (manual)

Zero friction to post but zero structure in what gets posted; a month later you have 60 messages with no searchable action-item history and no way to see what actually got resolved.

On Starch RECOMMENDED

One platform — project management, task manager, meeting notes all running on connected data. Setup in plain English; numbers stay current via scheduled syncs and live agent queries.

Try it on Starch →

FAQ

Frequently asked questions

Jira is our ticketing system but we also use PagerDuty for on-call. Can the standup include both?

Yes. Connect both Jira and PagerDuty from Starch's integration catalog. The agent queries them both live each morning. Your standup prompt can specify exactly which Jira project and which PagerDuty service IDs to include so you're not wading through alerts from other teams.

We use Jamf for device management. Can Starch pull Jamf data into the standup digest?

Jamf has a web-based admin console, so Starch can automate it through your browser — no API setup needed. You could add a step: 'Check Jamf for devices that have been offline for more than 3 days and include them in the digest.' That said, if you want deep scheduled sync of Jamf data, that's not a built-in scheduled-sync provider today — browser automation is the practical path.

What if our standup replies happen in Slack threads — can Starch read those?

Yes. Connect Slack from Starch's integration catalog. The agent can read channel messages and thread replies, extract commitments and blockers, and create tasks from them. Note that Starch syncs Slack channels and users — message-level reading happens via live query when the automation runs.

We're a 2-person team. Is this overkill?

A 2-person IT team supporting 300 users is exactly the case where async structure pays off most. When one of you is heads-down on a critical incident, the other shouldn't have to interrupt to get a status read. The digest takes the 'what's everyone working on?' question off the table so you can stay in flow.

Is Starch SOC 2 certified? We'd be piping Jira ticket data and AWS cost data through it.

Starch is not SOC 2 Type II certified yet. That's a real consideration if your company has strict data-handling requirements for internal tooling. Worth checking with your security lead before connecting production systems.

Can the standup surface flag when a ticket has had no update in over 24 hours?

Yes. Add that condition to your standup prompt: 'Flag any open P1 or P2 Jira ticket with no status change in the last 24 hours as a blocker.' The agent evaluates this at query time and includes it in the Blockers section of the digest automatically.