Action Rules & Automation

Automate resource lifecycle management with scheduled action rules to optimize costs, ensure uptime, and reduce manual operations.

What are Action Rules?

Action Rules are scheduled automation policies that automatically perform actions on your infrastructure resources at specified times. They enable you to implement cost-saving strategies, enforce operational policies, and reduce manual intervention.

Key Benefits:

Cost Optimization: Automatically stop non-production resources after hours (save up to 60-75% on compute costs)
Operational Efficiency: Eliminate manual start/stop operations
Policy Enforcement: Ensure dev environments don't run 24/7
Resource Cleanup: Automatically terminate old or unused deployments
Predictable Operations: Resources start when teams need them

Common Use Cases

💰 Cost Savings

Stop Dev After Hours
Stop development clusters at 6 PM, save 50+ hours/week
Weekend Shutdown
Stop test environments Friday evening, restart Monday morning
Savings Calculator
3x t3.medium nodes @ $0.0416/hr = $3/hr → $90/day → $27k/year
Stop 12hrs/day = $13.5k savings/year per cluster

🚀 Operational Efficiency

Morning Startup
Start staging at 8 AM before team arrives
Pre-Demo Preparation
Ensure demo environment is running before client meetings
Scheduled Scaling
Scale up before expected traffic, scale down after

🧹 Resource Cleanup

Terminate Old Deployments
Clean up feature branch deployments after 7 days
Remove Test Instances
Delete temporary instances created during testing
Orphaned Resources
Identify and remove resources no longer in use

🔒 Policy Enforcement

Compliance Requirements
Shut down dev with PII data after hours for security
License Management
Stop instances to stay within license limits
Budget Control
Prevent cost overruns from forgotten running resources

Creating Action Rules

Step 1: Navigate to Action Rules

Go to Organization Settings → Action Rules

Step 2: Click "Create Action Rule"

This opens the rule configuration dialog.

Step 3: Configure Rule Settings

Rule Name

Descriptive name (e.g., "Stop Dev Clusters After Hours")

Resource Filter (Regex)

Pattern to match resource names (e.g., dev-.* matches all resources starting with "dev-")

Resource Types

Select what to target: Applications, Instances, Clusters, Environments, Networks

Schedule

When to execute (predefined or custom cron)

Actions

What to do: Start, Stop, Terminate, Scale, etc.

Step 4: Test and Save

Preview matched resources before enabling. Once satisfied, save and activate the rule.

Schedule Types

Predefined Schedules

Common schedules ready to use:

Mon-Fri 8:00 AM ESTWeekday mornings

Mon-Fri 6:00 PM ESTWeekday evenings

Daily 2:00 AM ESTEvery night (off-hours maintenance)

Sundays 12:00 AM ESTWeekly cleanup

Custom Cron Expressions

For advanced scheduling, use cron syntax:

Format: minute hour day month day-of-week

Examples:
0 18 * * 1-5    # 6 PM, Monday-Friday
0 8 * * 1-5     # 8 AM, Monday-Friday  
0 0 * * 0       # Midnight every Sunday
*/30 * * * *    # Every 30 minutes
0 9,17 * * 1-5  # 9 AM and 5 PM, weekdays only
0 2 1 * *       # 2 AM on 1st of every month

Cron Helper:

Use crontab.guru to build and test cron expressions.

Timezone

All schedules use Eastern Standard Time (EST/EDT) by default. Plan accordingly if your team is in a different timezone.

Action Types

Start

Start stopped clusters or deployments. Scales resources back to configured replica counts.

Applies to: Clusters, Applications, Instances

Stop

Gracefully stop running resources. Scales to zero but preserves configuration for quick restart.

Applies to: Clusters, Applications, Instances

Terminate

Permanently remove resources. Cannot be restarted (must be redeployed).

Applies to: Deployments, Instances

Scale

Change replica count. Useful for scheduled capacity adjustments.

Applies to: Applications, Instances

Send Notification

Send alerts to Slack or email before taking action (useful for warnings).

Applies to: All resources

Resource Filters

Use regex patterns to target specific resources. Filters are case-insensitive.

Filter Patterns

# Exact match
^dev-cluster$          # Only "dev-cluster"

# Prefix match
dev-.*                 # All resources starting with "dev-"
staging-.*             # All resources starting with "staging-"

# Suffix match  
.*-test                # All resources ending with "-test"

# Contains
.*feature.*            # All resources containing "feature"

# Multiple patterns (OR)
(dev|test|staging)-.*  # Resources starting with dev, test, or staging

# Exclude production (NOT)
^(?!prod).*            # Everything except resources starting with "prod"

Resource Type Filters

Further narrow down by resource type:

☑️ Applications / Instances: Application templates and their instances
☑️ Clusters: Kubernetes clusters
☑️ Environments: Environment configurations
☑️ Networks: VPCs and networking resources

Multiple Actions

Chain multiple actions together in a single rule for complex workflows:

Example: Graceful Shutdown with Notification

Action 1: Send Slack notification "Dev cluster stopping in 5 minutes"
Action 2: Wait 5 minutes (delay)
Action 3: Stop cluster
Action 4: Send confirmation "Dev cluster stopped"

Example: Cleanup Old Deployments

Action 1: Filter deployments older than 7 days
Action 2: Stop matching deployments
Action 3: Wait 1 hour (delay)
Action 4: Terminate stopped deployments
Action 5: Send summary report to Slack

Real-World Examples

Example 1: Development Environment Cost Optimization

Goal: Reduce dev cluster costs by 60%

Rule 1: Stop Dev Clusters After Hours

Name: Stop Dev Clusters 6 PM
Filter: dev-.*
Resource Types: Clusters, Applications
Schedule: Mon-Fri 6:00 PM EST
Action: Stop

Rule 2: Start Dev Clusters Before Work

Name: Start Dev Clusters 8 AM
Filter: dev-.*
Resource Types: Clusters, Applications
Schedule: Mon-Fri 8:00 AM EST
Action: Start

Cost Savings:

Running: 10 hrs/weekday + 0 hrs/weekend = 50 hrs/week
Stopped: 14 hrs/weekday + 48 hrs/weekend = 118 hrs/week
Savings: 70% reduction in runtime
Annual savings: ~$18,900 per cluster

Example 2: Feature Branch Cleanup

Goal: Auto-cleanup feature branch deployments after PR merge

Rule: Terminate Old Feature Deployments

Name: Cleanup Feature Branches
Filter: .*-feature-.* or .*-fb-.*
Resource Types: Instances, Deployments
Schedule: Daily 2:00 AM EST
Condition: Older than 7 days AND not marked as main
Action: Terminate

Benefits:

✓ Prevents cluster congestion from forgotten deployments
✓ Reduces costs from unused resources
✓ Keeps environments clean and organized
✓ Eliminates manual cleanup tasks

Example 3: Load Test Preparation

Goal: Auto-scale staging for weekly load tests

Rule 1: Scale Up Before Load Test

Name: Scale Staging for Load Test
Filter: staging-api
Resource Types: Applications
Schedule: Fridays 1:00 PM EST
Action: Scale to 10 replicas

Rule 2: Scale Down After Load Test

Name: Scale Down Staging
Filter: staging-api
Resource Types: Applications
Schedule: Fridays 5:00 PM EST
Action: Scale to 2 replicas

Best Practices

DO:

✓ Test rules in dev environment before applying to production
✓ Use descriptive names that explain what the rule does
✓ Add Slack notifications before destructive actions (terminate)
✓ Preview matched resources before enabling a rule
✓ Document rule purpose and expected behavior
✓ Start with conservative filters (match fewer resources)
✓ Monitor rule execution logs regularly
✓ Set up alerts for rule failures

DON'T:

✗ Create rules that affect production without thorough testing
✗ Use overly broad filters (e.g., .* matches everything!)
✗ Terminate resources without stop-first grace period
✗ Forget to communicate schedule changes to the team
✗ Set rules to run during peak hours
✗ Ignore failed rule executions
✗ Create conflicting rules (start and stop at same time)

Monitoring & Logs

SeaGit provides comprehensive logging for all action rule executions:

Execution History

View past rule runs with timestamps, matched resources, and outcomes.

Success/Failure Status

Track which actions succeeded and which failed, with error details.

Resource Impact

See exactly which resources were affected by each rule execution.

Cost Savings Reports

Estimate cost savings from automated stop/start rules.

API Reference

List Action Rules

GET /api/v1/arules

Response:
{
  "rules": [
    {
      "id": "rule-123",
      "name": "Stop Dev Clusters After Hours",
      "filter": "dev-.*",
      "resource_types": ["clusters", "applications"],
      "schedule": "0 18 * * 1-5",
      "action": "stop",
      "enabled": true
    }
  ]
}

Create Action Rule

POST /api/v1/arules

{
  "name": "Stop Dev Clusters 6 PM",
  "filter": "dev-.*",
  "resource_types": ["clusters"],
  "schedule": "0 18 * * 1-5",
  "action": "stop",
  "enabled": true
}

Response: 201 Created
{
  "id": "rule-124",
  "name": "Stop Dev Clusters 6 PM",
  ...
}

Preview Matched Resources

POST /api/v1/arules/preview

{
  "filter": "dev-.*",
  "resource_types": ["clusters"]
}

Response:
{
  "matched_resources": [
    {"id": "cluster-1", "name": "dev-cluster-1", "type": "cluster"},
    {"id": "cluster-2", "name": "dev-cluster-2", "type": "cluster"}
  ],
  "count": 2
}

View Execution History

GET /api/v1/arules/rule-123/executions

Response:
{
  "executions": [
    {
      "id": "exec-456",
      "executed_at": "2024-01-15T18:00:00Z",
      "status": "success",
      "resources_affected": 3,
      "duration_ms": 12543
    }
  ]
}

Troubleshooting

Rule not matching expected resources

Solution: Use the preview endpoint to test your filter before enabling the rule.

Rule execution failed

Common causes: Resource already in target state, insufficient permissions, resource locked by another operation

Solution: Check execution logs for specific error, ensure rule has proper permissions

Rule didn't run at scheduled time

Check: Verify rule is enabled, cron syntax is correct, and timezone matches your expectation (EST)

Previous: Variables & Secrets Next: Getting Started Guide