Your team set up a cron job. Probably six months ago, maybe longer. It stops EC2 dev instances at 10 PM and starts them again at 7 AM. Someone spent an afternoon wiring it up — a Lambda, a CloudWatch Events rule, maybe an AWS Instance Scheduler stack — and it felt like a win.
It is a win. Compared to nothing, a fixed schedule is real savings. But here is what that schedule actually models: everyone starts at exactly 7 AM, works continuously until exactly 10 PM, and nobody takes a lunch break, attends a three-hour meeting, or leaves early on a Friday.
Nobody works like that. And AWS bills by the second, so every gap between the schedule and reality is money leaving the account for compute that no human is using.
What the Schedule Actually Covers
Let's be concrete. Say your team is eight engineers in two time zones. The schedule runs Monday through Friday, 7 AM–10 PM in your primary zone. That's 15 hours of uptime per weekday, 0 on weekends.
Weekday uptime: 15 hours
Weekend uptime: 0 hours
Total per week: 75 hours (15 × 5)
Total per week, unmanaged: 168 hours
Schedule coverage: 75 / 168 = ~44.6%
Fair. That schedule eliminated more than half the potential uptime. Now look at what it doesn't cover.
A senior engineer in your western office starts at 9 AM local time — two hours after the instance is already running. She has a two-hour all-hands on Tuesday. She's out sick Thursday. Her instance is running and billing from 7 AM regardless.
Another engineer wraps up by 5 PM most days. The instance runs until 10 PM.
Multiply this across eight engineers. You're running instances for stretches that map to no human work at all — not nights or weekends, but the quieter idle time baked into every real workday: mornings before anyone logs in, lunch hours, meetings, end-of-day gaps before the cron fires.
The schedule didn't solve idle time. It solved predictable idle time. The unpredictable kind — the kind that follows actual human behavior — it can't touch.
Why Fixed Schedules Can't Go Further
The instinct when you notice this is to tighten the schedule. Push the start time later, pull the stop time earlier, add a weekend rule. But this runs into a hard wall fast.
Schedules are global. A tighter window that works for your latest-starting engineer leaves your earliest engineer waiting for their instance. You can try per-engineer schedules, but now you're maintaining eight sets of CloudWatch rules and someone's schedule is always wrong after a timezone change or a hire.
More importantly: schedules are static models of a dynamic thing. Human presence during a workday is not a block. It's a pattern of focus, interruption, and absence that changes every day. A meeting runs long. Someone gets pulled onto an incident. The schedule doesn't know any of this.
The other approach — server-side metrics — doesn't solve it either. Low CPU on an EC2 instance means the machine isn't doing much, but it doesn't tell you whether an engineer is actively working in their IDE with the instance open in a terminal. Background processes, keep-alive connections, and idle shells all keep metrics above zero without any human present. You end up with false positives that train your team not to trust the automation, so they disable it.
Activity-Driven: What It Actually Means
Activity-driven pause/resume — the approach Trigops takes — means the signal for stopping or starting a resource comes from observed human presence and work-tool focus on the engineer's local machine, not from a clock or from server-side metrics.
The practical shape of this: a lightweight desktop agent on the engineer's machine watches whether they're actively using tools associated with that instance (terminal sessions, IDE connections, AWS console activity). When the engineer stops working — closes the session, switches to Slack and stays there, locks their screen — the agent detects the transition and signals the associated EC2 instance to pause. When they return to active work, the instance resumes.
This is not a schedule. There is no 10 PM rule. The instance pauses when this engineer, today, right now is not using it — and resumes when they are.
The result is that idle time tracks the actual gaps in each engineer's day, not a shared approximation of when the whole team might be working.
The Architecture Difference
Here is how the two approaches compare at the decision point — the moment of deciding whether to stop a resource:
# Fixed schedule (CloudWatch Events / Instance Scheduler)
Input: current time
Rule: if time == "22:00", stop
Result: all instances in scope stop, regardless of who is using them
# Activity-driven (Trigops)
Input: desktop agent signal — engineer X is idle / active
Rule: if engineer X is idle, pause engineer X's associated resources
Result: that engineer's EC2 (or ECS service, RDS, ASG) pauses;
engineer Y, who is still working, is unaffected
The schedule operates at the account or tag level. Activity-driven operates at the engineer level and propagates to their resources.
This matters for multi-account and multi-region teams. If you have a platform team running dev infrastructure across several AWS accounts, a schedule either covers all of them identically or you're managing a proliferation of rules. Activity-driven control stays coherent at the per-engineer, per-resource level regardless of how many accounts or regions the resources live in.
What Resources This Applies To
The resources where this makes the most practical difference are the ones tied to individual developer workflows.
EC2 dev boxes are the clearest case. One engineer, one instance, a direct mapping between human presence and resource need. When the engineer isn't there, the instance doesn't need to run.
ECS services in dev/staging are trickier with schedules because they often have dependencies and minimum task counts that make blanket stop/start risky. Activity-driven control can scope the pause to a specific service without touching the rest of the cluster, and it only fires when nobody is actively using that service — not at an arbitrary time.
RDS instances are expensive to run continuously and slow to stop/start, which is exactly why teams avoid scheduling them: the risk of stopping a shared staging database mid-use is real. Activity-driven control, tied to whether anyone has an active connection through their workstation, provides the signal that a schedule can't.
Auto Scaling Groups are the most complex case. The minimum capacity floor that someone set before a demo is now a permanent floor that nobody reviews. Activity-driven approaches can inform when the floor can safely drop — not by overriding the ASG min directly, but by detecting when no engineer is actively using the environment and signaling a scale-down.
The Real Cost of "Good Enough"
A fixed schedule is not wrong. For a solo project or a team with very predictable hours, it might be genuinely sufficient. The argument here is not that schedules are bad — it's that they have a ceiling, and that ceiling is lower than most teams assume.
The ceiling becomes visible when you look at instance-hours. A schedule that runs 7 AM–10 PM captures the nights and weekends. The instance-hours lost to within-day idle time — meetings, gaps, asynchronous work patterns, time zones — sit inside the schedule window and are invisible to it.
Those hours are not catastrophic individually. Across a team over a month, they add up to a billing line that the schedule was supposed to eliminate.
Replacing the Cron
The operational argument for dropping the fixed schedule in favor of activity-driven control is not just cost. It's maintenance.
Cron jobs and CloudWatch rules have owners, and owners leave. The schedule that's running your EC2 stop/start today was probably set up by someone who has since moved to a different role or left the company. The logic lives in a Lambda function in a region someone had to remember to check. The schedule is six months stale and nobody is confident enough to change it.
Activity-driven automation has no schedule to go stale. The pause/resume decision is made fresh on every session, based on what the engineer is actually doing. There is nothing to update when a new hire joins or when a team shifts to async-first.
You stop managing a schedule. The resources manage themselves around the people using them.
If your team is running EC2 dev boxes, staging ECS services, or shared RDS instances on a fixed stop/start schedule — or no schedule at all — Trigops does the activity-driven layer. It connects to your AWS accounts, maps resources to the engineers who use them, and pauses them when those engineers are idle. No cron required.
trigops.com — connect a cloud account and see which of your resources are running when nobody is home.
