The Sabotage Series #1: The Log Cleaner That Cleaned Too Much

The Sabotage Series #1: The Log Cleaner That Cleaned Too Much

Welcome to The Sabotage Series

Every SRE eventually learns this lesson: automation does not remove risk. It concentrates it.

I learned that the hard way after one of those 2:00 AM pager alerts nobody forgets. Disk space was falling fast on a production IIS server, the alert was noisy, and the cleanup job that was supposed to prevent the problem had been running successfully for weeks.

At least, that is what the logs said.

This series is about learning through broken code. Each post presents a small piece of automation with a real-world flaw hiding inside it. Your job is to find the logic bomb before it finds production.

The Setup

The task sounded simple: clean up old IIS log files before they filled the system drive.

The automation was supposed to:

  • Scan the IIS log directory.
  • Find log files older than 30 days.
  • Delete only those expired IIS logs.
  • Write a short operational message for the next person on call.

Clean. Routine. Safe.

Or so it looked.

The Code

Here is the PowerShell script that made it into the scheduled task:

$LogRoot = "C:inetpublogs"
$RetentionDays = 30
$CutoffDate = (Get-Date).AddDays(-$RetentionDays)

Write-Output "Starting IIS log cleanup for files older than $RetentionDays days..."

Get-ChildItem -Path $LogRoot -Recurse |
    Where-Object { $_.LastWriteTime -lt $CutoffDate } |
    ForEach-Object {
        Remove-Item -Path $_.FullName -Force
        Write-Output "Deleted: $($_.FullName)"
    }

Write-Output "IIS log cleanup completed."

The Challenge

This script is broken.

The dangerous part is not obvious at first glance, and that is exactly why this kind of automation survives code review, gets scheduled, and waits quietly for the wrong directory structure or file pattern to appear.

Your mission:

  • Find the hidden flaw.
  • Post the corrected PowerShell syntax in the comments.
  • Bonus challenge: write the equivalent safe fix in Python.

Do not just make it work. Make it safe. Think about filters, blast radius, dry runs, logging, and what happens when the filesystem does something you did not expect.

I will break down the failure mode and a hardened version in the follow-up.

Leave a Reply

Your email address will not be published. Required fields are marked *