Yesterday I showed Kiro Crew investigating a production incident in 33 seconds. Reactive. Impressive. But still reactive.
This week I asked a different question. What if the agent ran my boring weekly rituals while I slept? The dependency checks I never get to. The stale branches nobody cleans up. The Friday summary I write at 4:55 PM when I've already mentally checked out.
I set up 6 cron jobs. Recorded the whole thing. Then walked away.
I planned to cover security next (I said so at the end of Part 2). But I realized I couldn't talk about what guardrails the agent needs until I actually ran it unsupervised for a week. So this is that week. Security comes in Part 4, informed by what I learned here.
Table of Contents
- The problem: 4 hours of weekly toil
- Job 1: Monday morning health report
- Job 2: Daily dependency vulnerability scan
- Job 3: Git hygiene check
- Job 4: Documentation freshness audit
- Jobs 5+6: Resource monitoring + Friday EOW summary
- Triggering a job live
- The dashboard: proof it all works
- What this costs
- Try it yourself
The problem: 4 hours of weekly toil
I tracked my repetitive DevOps tasks across three client projects for two weeks. Same pattern everywhere:
| Task | Frequency | Time spent |
|---|---|---|
| Check system health, summarize issues | Monday morning | 25 min |
| Scan dependencies for vulnerabilities | Should be daily, actually ~weekly | 30 min |
| Clean up stale branches, review PRs | Twice a week | 20 min |
| Verify docs match reality | When someone complains | 35 min |
| Check resource usage trends | Wednesday-ish | 15 min |
| Write end-of-week deployment summary | Friday 5 PM (rushed) | 30 min |
Total: roughly 4 hours/week of work that's important but never urgent. The kind of work that slips until something breaks.
None of this requires creativity. It requires discipline. And discipline is exactly what a scheduled agent is good at.
I'll be honest: the first week wasn't clean. Three of the six jobs produced outputs I didn't fully trust. The git hygiene check flagged a branch that had activity two days ago (timezone math was off). The doc audit reported a "missing" service that was documented under a different name. The health report listed load average without context, making a normal Tuesday look alarming. I fed corrections back each time. By week two, the outputs tightened up. By week three, I stopped second-guessing them. That calibration period matters. Don't expect perfection on day one.
Job 1: Monday morning health report
Create a cron job called 'monday-health-report' that runs every Monday at 8 AM.
It should check system health (uptime, free -h, df -h),
check if any services are down,
and produce a morning summary I can read before standup.
The agent created the job in 18 seconds. Every Monday at 8 AM it now checks uptime, memory, disk, and load average. By the time I open my laptop, there's a summary waiting.
Before: I'd SSH into three servers, run the same five commands, copy the output into Slack, and pretend I'd been thorough.
Now: it's done before my coffee is ready.
Job 2: Daily dependency vulnerability scan
Create a cron job called 'daily-dep-scan' that runs every weekday at 9 AM.
Scan for dependency vulnerabilities: check package.json files,
check requirements.txt for known CVEs,
and flag anything critical with a fix suggestion.
This one immediately found problems. My payment-service had axios 0.21.1 (prototype pollution vulnerability), lodash 4.17.20 (command injection), and jsonwebtoken 8.5.1 (JWT verification bypass).
Those packages had been vulnerable for months. I knew I should check. I kept pushing it to "next sprint."
The agent doesn't push things to next sprint.
Job 3: Git hygiene check
Create 'git-hygiene-check' running Tuesday and Thursday at 10 AM.
Find branches with no activity in >7 days,
identify WIP commits that were never finished,
check for any branches that should be merged or deleted.
First run found four stale branches in my demo project:
-
feature/old-api-migration— 19 days stale, one WIP commit -
feature/abandoned-refactor— 17 days stale, commit message literally says "half-done, switching to other task" -
hotfix/temp-logging— 12 days stale, verbose logging that should have been removed -
feature/experimental-cache— 9 days stale, memcached experiment that went nowhere
It correctly identified feature/add-webhooks as recent and active (1 day old). No false positives.
Every team I've consulted for has this problem. Branches accumulate like browser tabs. Nobody wants to be the one who deletes someone else's work. The agent doesn't have those feelings.
Job 4: Documentation freshness audit
Create 'doc-freshness-audit' running every Thursday at 2 PM.
Check README.md against actual project structure:
are all services documented? Are environment variables listed?
Are port numbers and endpoints accurate?
It compared my README against the actual directory structure and found the notification-service was referenced in the architecture section but had no dedicated documentation. Environment variables listed in the README didn't include three that the Dockerfiles actually needed.
Documentation drift is invisible until a new team member joins and can't get the project running. This catches it weekly instead of quarterly.
Jobs 5+6: Resource monitoring + Friday EOW summary
Job 5: 'resource-usage-check' every Wednesday at 11 AM —
check disk usage, memory, and system load trends.
Flag if anything is above 80%.
Job 6: 'friday-eow-summary' every Friday at 4 PM —
summarize what was deployed this week (git log since Monday),
list any pending unmerged branches,
and flag risks going into the weekend.
The agent created both in one response. Resource check flags capacity issues before they become incidents. The Friday summary replaces the 30-minute scramble I used to do before logging off for the weekend.
The Friday summary is my favorite. It reviews git log --since="last Monday", counts deployments, identifies unmerged branches, and flags anything risky going into two days of nobody watching. It's the handoff note I always meant to write but never did.
Triggering a job live
To prove these aren't just entries in a database, I triggered the git-hygiene-check manually:
Trigger the 'git-hygiene-check' job manually.
Run the actual git analysis right now.
44 seconds later, a full report. Stale branches identified. WIP commits flagged. Cleanup commands ready to copy-paste. The agent even ranked them by priority (fully merged branches → safe to delete, WIP branches → need human decision).
This is what runs automatically every Tuesday and Thursday at 10 AM. No human involvement. No forgotten tasks. No guilt about that branch from three weeks ago.
The dashboard: proof it all works
The Schedule tab tells the full story. All six jobs visible. Schedules confirmed. Status indicators showing which have run and which are queued.
The weekly pipeline:
- Monday 8 AM: Health report + infrastructure status
- Weekdays 9 AM: Dependency vulnerability scan
- Tue/Thu 10 AM: Git hygiene check
- Wednesday 11 AM: Resource usage monitoring
- Thursday 2 PM: Documentation freshness audit
- Friday 4 PM: End-of-week deployment summary
Monday through Friday, covered. Zero manual intervention after the initial setup.
What this costs
Each cron job execution uses roughly 3,000-5,000 tokens. At Claude Sonnet pricing:
| Job | Frequency | Weekly cost |
|---|---|---|
| Health report | 1x/week | $0.04 |
| Dep scan | 5x/week | $0.20 |
| Git hygiene | 2x/week | $0.08 |
| Doc audit | 1x/week | $0.04 |
| Resource check | 1x/week | $0.04 |
| Friday summary | 1x/week | $0.04 |
| Total | 11 runs/week | ~$0.44/week |
Call it $2/month. Compare to 4 hours × $100/hr engineering time = $1,600/month.
ROI: 800x. And the agent doesn't skip tasks because the sprint got busy.
Try it yourself
Same setup as Part 2. Kiro Crew is open source (Apache 2.0).
Prerequisites: Python 3.10+, Node.js 18+, Kiro CLI signed in.
# Install
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh
# Start
kirocrew gateway
Create a project with some realistic history:
mkdir my-platform && cd my-platform && git init
# Add some commits
git commit --allow-empty -m "feat: add payment service v2.3"
git commit --allow-empty -m "chore: bump dependencies (aws-sdk, pg-pool)"
git commit --allow-empty -m "deploy: payment-service v2.3.1 to production"
# Create a stale branch
git checkout -b feature/abandoned-experiment
git commit --allow-empty -m "wip: trying something"
git checkout main
# Add a package.json with some outdated deps
echo '{"dependencies":{"axios":"0.21.1","lodash":"4.17.20"}}' > package.json
git add -A && git commit -m "chore: initial deps"
Then ask the agent to set up your automation:
Create 6 weekly cron jobs:
1. 'monday-health-report' - Mon 8 AM - system health summary
2. 'daily-dep-scan' - Weekdays 9 AM - vulnerability scan
3. 'git-hygiene-check' - Tue/Thu 10 AM - stale branches and WIP cleanup
4. 'doc-freshness-audit' - Thu 2 PM - README vs reality check
5. 'resource-usage-check' - Wed 11 AM - disk/memory/load monitoring
6. 'friday-eow-summary' - Fri 4 PM - deployment summary + weekend risks
Set approval to "Trust" and watch it build your automation pipeline.
kirodotdev
/
KiroCrew
A persistent workspace for development work that self-improves and continues beyond one session.
Kiro Crew
A persistent workspace for development work that self-improves and continues beyond one session.
Kiro Crew is an open source development workspace that runs locally or remotely on your hardware. It is persistent, self-learning, and self-evolving. Work with it from the desktop app, web dashboard, and CLI, or continue the same work through connection tools like Slack and Discord Your multi-step tasks can run unattended, recurring jobs run on your schedule and heartbeats monitor systems until something needs attention. Kiro Crew Apps tailor that experience to a specific job, combining a purpose-built interface with agents, skills, schedules, integrations, and backend services.
Quick start · Build from source · Why Kiro Crew · Capabilities · How it works · Security · Install · Telemetry · Docs
Quick start
You choose how to run Kiro Crew: the desktop app with automatic updates, a one-line install on your machine or a remote…
What I'd change for a real team
For a production team, I'd add three things:
Slack/Teams integration. These reports should land in a channel, not just the Kiro Crew dashboard. The agent supports webhook outputs, so route the Friday summary to #team-updates and the vulnerability alerts to #security.
Escalation logic. If the dep scan finds a critical CVE, don't just report it. Create a Jira ticket. Tag the service owner. Set a deadline. The agent can do this with the right tools configured.
Historical trending. Each report should compare to last week. "Disk usage: 67% (up from 52% last week)" is more useful than "Disk usage: 67%." Feed previous outputs back as context for the next run.
This is Part 3 of my Kiro Crew series. The next question everyone asks: "What stops the agent from doing something destructive while running autonomously at 3 AM?" Part 4 answers that with a full security model walkthrough.
What's your most hated weekly ritual? The one you keep meaning to automate but never do? Mine was the Friday summary. Yours might be different. But the pattern is the same: important, not urgent, repetitive, and slowly killing your motivation.
Follow me for more on AWS architecture, DevOps, and AI Infrastructure:
Portfolio | LinkedIn | Dev.to | YouTube | Email | AWS Builder Center
Top comments (1)
📌 Part 1: Introducing Kiro Crew: AWS's Open-Source AI Agent Orchestrator - What it is, how it works, why 39K+ Amazon builders adopted it
📌 Part 2: I Spent a Day With Kiro Crew. Here's What It Actually Does. - P1 incident investigated in 33 seconds, $0.04 per investigation
📌 Part 3: You're reading it - 6 cron jobs replacing 4 hours of weekly toil for $2.10/week
Next up: Part 4 covers the security model. What stops the agent from doing something destructive at 3 AM? 8 layers, 137 deny patterns, signed audit logs.
What's the one weekly ritual you'd automate first? For me it was the Friday EOW summary. Curious what yours is 👇