PowerShell is an object-oriented scripting language, which means it processes code from top to bottom, right? Well, think again! PowerShell is a nice combination of .NET and some low end features which enables you to do amazing stuff.

For those who are reading my blogs, I Like event driven architecture (my god, again?!) Yes again! Can’t emphasize enough how much I like this 😁

So, after the blogs about Azure event-driven architecture, I was in the mood for creating something in PowerShell! I hear you thinking, “PowerShell, Event-Driven? What the hell?!”.

Yeah, it’s possible! In this blog post, I’ll guide you with some good old-fashioned examples on how to create event-driven architecture within your PowerShell scripts!

During this post, you’ll see this icon 🎬, which indicates that action is required so you get the full benefit out of this post.

And I’ve introduced the 📒, which indicates that the subsequent part explains the technical details in the context of this post.

Let’s get started!

In our toolbelt

Today’s cmdlet (short for ‘commandlet’) is called… 🥁🥁🥁 “Register-ObjectEvent”.

This cmdlet is part of the Microsoft.PowerShell.Utility module that allows us to subscribe to .NET object events. Mouth full, yes, but we can do magical things like:

•  File Watchers
• Timers
• WMI Event Subscriptions
• GUI Controls, etc.

🤔 So, How Does It Work?

Well, when you register an event, PowerShell says “don’t worry, I got this,” and quietly spins up a background runspace (think of it like an invisible coworker that does the job for you while you sip coffee ☕).

That coworker is an EventHandler, who lives to respond to stuff like “Hey! A file was created!” or “Yo, timer went off!” or “That process you wanted? It just started!”

So in this post, we’ll be dealing with that!

Let’s get started 🚀

Let’s get Script-y!

Let’s say you want to monitor your filesystem. You want to be informed as soon as something on your filesystem changes. Well, this cmdlet got your back like a true detective!

🎬 Make the scripts below and lets get started!

1. Create a directory ‘ImportantStuff’ on your c drive
2. Run the script below

$fsw = New-Object IO.FileSystemWatcher 
$fsw.path = "C:\ImportantStuff"
$fsw.EnableRaisingEvents = $true
$fsw.IncludeSubdirectories = $false
Register-ObjectEvent -InputObject $fsw -EventName Created -Action {
    Write-Host "A new file or directory appeared! Someone’s writing secrets again..."
}

$fsw = New-Object IO.FileSystemWatcher 
$fsw.path = "C:\ImportantStuff"
$fsw.EnableRaisingEvents = $true
$fsw.IncludeSubdirectories = $false
Register-ObjectEvent -InputObject $fsw -EventName Created -Action {
    Write-Host "A new file or directory appeared! Someone’s writing secrets again..."
}

This now does the following:

1. It creates a listener to the directory  (but doesn’t lock the thread!)
2. When a change occurs, the event is triggered and the event handler notified
3. The event handler deals with our business logic

🎬 Now make a change in the directory we just created and check the powershell window. You should see something like below

🥳 Success! Our event handler is picking up the changes (Event driven!)

Leveling it up with a custom event

In the previous example, we’ve seen how to subscribe to an event handler which is already built-in from the .NET stack. But you can also create your own custom event and event handlers!

In this part, we’ll be focusing on that!

🎬 Follow the steps below to create a custom event handler

• Create a file ‘Event.ps1’ and give it the code below

Register-EngineEvent -SourceIdentifier 'MyCustomEvent' -Action {
    Write-Host "🎉 Custom event triggered! Message:" $Event.MessageData
}

Register-EngineEvent -SourceIdentifier 'MyCustomEvent' -Action {
    Write-Host "🎉 Custom event triggered! Message:" $Event.MessageData
}

• Save the file and start a PowerShell session
• In the PowerShell session we’ll call the event handler file

• We now have the event handler registered and ready to do it’s job!
• In the same PowerShell session we’ll now be informing the event handler that an event has been raised. Provide the following code to raise an event:

new-event -SourceIdentifier 'MyCustomEvent' -MessageData "Hello from this trigger"

new-event -SourceIdentifier 'MyCustomEvent' -MessageData "Hello from this trigger"

• You’ll see our event handler picking up the event:

🧪 Explanation

🧼 Cleanup Reminder

📒 When done, clean up your subscribers or your session may leak memory or leave ghost listeners:

Unregister-Event -SourceIdentifier MyCustomEvent

Remove-Event -SourceIdentifier MyCustomEvent

Use cases

Sometimes, you don’t need to wait for a file to change or a process to spawn just to trigger some logic. Sometimes, you just want to raise your own hand and say, “Hey PowerShell, do the thing now.” That’s where custom events come in. They let you build your own little event system without needing a fancy .NET object or some external trigger. Whether you’re managing background jobs, reacting to timers, or keeping different parts of your script loosely coupled and organized, custom events give you a clean and powerful way to handle it. Here’s a quick look at some actually useful, real-world use cases for them:

🔁 1. Background Job Notifications

Let’s say you kick off a background job to do something heavy, compress files, query a huge database, whatever. Instead of constantly checking Get-Job like a babysitter, you register a custom event that fires when the job finishes!

⏱️ 2. Central Timer with Multiple Actions

You’ve got a timer ticking every 5 seconds. Instead of hardcoding logic into one action, raise a custom event that multiple parts of your script can listen to.

🔄 3. Command Triggering Within Scripts

Need to trigger different behaviors without building a massive switch or if/else chain? Use custom events like internal commands!

Summary

That’s it,  event-driven PowerShell, in action! 🧨
In this post, we stepped away from the traditional “top-to-bottom” script mindset and looked at how PowerShell can listen, react, and even raise its own custom events. Whether it’s using Register-ObjectEvent to monitor file changes or Register-EngineEvent to build your own internal trigger system, you now have the tools to make your scripts smarter, cleaner, and way more responsive.

We covered real examples, from file watchers and timers to custom events triggered on-demand. And the best part? You didn’t need to spin up a giant cloud service or build an entire backend. Just plain old PowerShell, lean, mean, and event-driven. 💥

If you’re working with automation, background jobs, or just want to structure your scripts like an actual system instead of a spaghetti bowl of if statements, custom events are your new best friend.

Thanks for reading! Got questions, ideas, or cool event-driven use cases of your own? Drop them in the comments or ping me, I’d love to see what you’re building.
And as always, check out the other posts on this blog for more on scripting, automation, and my ongoing love affair with event-driven architecture. 😁

Until next time, keep scripting, keep reacting! 🚀