Catch the Traffic Before You Cut It Off: Auto-Capturing a PCAP with Event Handler + Soracom Flux

TL:DR

• Automating SIM suspension saves costs but obscures the evidence needed to diagnose the underlying cause of high data usage.
• You can solve this by using an Event Handler to trigger a Soracom Flux flow instead of suspending the SIM immediately.
• This flow starts a packet capture (PCAP) using Soracom Peek, waits for the capture to finish, and only then suspends the SIM, ensuring you have the evidence you need before cutting off traffic.

---

The 10 GB Weekend

A field device sits on a cellular router, quietly reporting a few hundred kilobytes an hour. Then, over a holiday weekend, it burns through 10 GB in two days, hits the monthly data threshold you configured, and an Event Handler dutifully deactivates the SIM to stop the bleeding. Crisis contained.

Except now you are staring at a bill and a question you cannot answer: what data was actually being sent? The traffic is gone, the SIM is dark – and the next time it happens, the result will likely stay the same.

This situation is frustratingly common, and comes down to a design tension that is worth understanding before we fix it.

---

Why You Have to Catch the Traffic Live

Soracom operates at the cellular network layer, and does not inspect or log the contents of your traffic by design. That is good for privacy and security, but it means that, after the fact, neither you nor Soracom can look at a payload and say “it was uploading camera frames” or “a logging agent was stuck in a retry loop.” Our records can tell you how much moved, in which direction, and when, but not what data was moved.

The only way to get definitive evidence of what a device is sending is to capture it while it is happening with Soracom Peek, which records a packet sample (a PCAP) showing destination IPs, ports, and protocols.

That creates the conflict: the moment your usage threshold trips, you want to suspend the SIM to stop the spend, but suspending it also ends the very traffic you need to see to diagnose the problem. You want both, in the right order: capture first, then suspend.

You can get exactly that by combining two Soracom services that most people use separately:

• Event Handler detects the threshold breach, fires a webhook, and emails you.
• Soracom Flux receives that webhook, starts a packet capture, waits, and only then suspends the SIM, using Flux’s action delay as a built-in timer.

The rest of this post will walk through building this solution, as well as a related pattern for tiered suspensions.

---

Pattern 1: Tiered Suspensions That Don’t Lock You Out

First, let’s look at a gotcha that trips up almost everyone who automates data limits.

When a SIM hits a monthly data limit and an Event Handler suspends it, the monthly data counter does not reset once the SIM is reactivated. So if your rule is allowed to re-evaluate after manually changing the SIM back to Active, it will see the SIM as still over the limit and suspend it again the instant it sends a packet. You will be locked out.

If you want tiered behavior – for example: suspend at 10 GB, let the team look, then again at 20 GB and 30 GB – the clean pattern is one Event Handler per step, each with its re-evaluation set to the beginning of next month:

• Handler 1: Rule “Monthly SIM data > 10 GB”, Action “Suspend SIM”, Re-evaluation “Beginning of next month”.
• Handler 2: Rule “Monthly SIM data > 20 GB”, Action “Suspend SIM”, Re-evaluation “Beginning of next month”.
• Handler 3: Rule “Monthly SIM data > 30 GB”, Action “Suspend SIM”, Re-evaluation “Beginning of next month”.

When the SIM crosses 10 GB, Handler 1 suspends it and then locks itself until next month, so it will not re-fire. When you reactivate, the SIM runs freely until 20 GB, where Handler 2 takes over, and so on. Each step fires exactly once. If you want to use this structure in the second pattern below, you will need to create multiple Event Handlers with different data thresholds in Step 4.

---

Pattern 2: Capture, Then Suspend

Now the main event. The flow we are building has three moves:

1. The Event Handler detects the threshold breach and sends an Execute Web Request to Flux, carrying the SIM ID in the body: { "simId": "..." }.
2. Flux Channel 1 (triggered via an incoming webhook) starts a packet capture then republishes its output to Channel 2 with a 300 second delay.
3. After the delay, Flux Channel 2 suspends the SIM.

The key to this trick is the delay on move 2. The capture starts immediately and auto-stops after its duration. Flux holds the republish that triggers the suspend for that same duration, so the SIM stays up just long enough to record a sample, then goes down. Flux’s delay is acting as a timer.

---

Step 1: Create the Flux app and an inbound webhook

Additional details about Soracom Flux can be found in its documentation.

1. In Soracom Flux, create an app and add an API channel.
2. In the channel settings, click Create incoming webhook and copy the URL.

---

Step 2: Start the packet capture and add the delay

In the channel’s Actions tab, add a Soracom API Action:

• API: createSimPacketCaptureSession
• URL: /v1/sims/${event.payload.simId}/packet_capture_sessions
• Body: { "duration": 300, "prefix": "flux-alert" }
  • Duration specifies the length of the packet capture in seconds, while the prefix will show up in our list of packet captures for this SIM in the UI for easy identification.
• Output: Enable “Republish the action output to another channel” and create a new channel.
• Advanced Settings: Set Delay to the same value as your capture duration (300 seconds in our example).

---

Step 3: Suspend the SIM after the timer

In the second channel, add another Soracom API Action:

• API: suspendSim or deactivateSim
• URL: /v1/sims/${event.payload.simId}/suspend

Because this channel is only reached via the delayed republish, the suspend runs after the capture window has closed.

Tip: Use deactivateSim (Inactive) rather than suspendSim (Suspended) for short durations to avoid reactivation fees. See Subscriber Statuses for details.

Your final Flux App will look like this:

---

Step 4: Create the Event Handler

Additional details about Event Handler can be found in the corresponding documentation.

1. Choose your target; Operator or Group will likely be the best for your use case.
2. Select a data usage rule (e.g., SimMonthlyTrafficRule) and set your usage threshold.
   • Set the Re-Evaluate period to ‘Beginning of Next Month,’ so that the traffic starts tracking again at the start of the next month for the SIM that triggers the rule. 
   • Ensure that “Do not execute again until next re-evaluation” is not checked, so this rule will trigger for multiple SIMs in the group or operator.
3. For the first action, choose Execute Web Request.
   • Point the URL to your Flux App’s Incoming Webhook URL from step 1.
   • Set the HTTP Method to POST, Content-Type to application/json, and pass the SIM’s identifier in the Body using Event Handler variables so Flux knows which SIM triggered the alert: {"simId": "${simId}"}.
4. Add a second Email action to alert you of the Rule being triggered and configure it as needed. You can use the ${simId} variable in your email message to alert you to which SIM triggered the rule.
5. If desired, add a third Activation action to run at the “Beginning of Next Month.” This will queue the SIMs’ reactivation at the start of the next month. You may leave this action out if you would rather manage SIM reactivation manually, or change its run timer to something else.

Test it safely: point the Event Handler at a single test SIM with a low threshold first. Once the flow behaves as expected, switch the target and threshold to production values.

---

Getting Your PCAP

After the alert fires and the capture finishes:

1. In the User Console, open SIM Management.
2. Select the SIM and click Details.
3. Open the Packet Capture tab and find the flux-alert session.
4. Click Get Link to download and open in Wireshark.

Now you can see the destination IPs, ports, and protocols, which usually makes the responsible process obvious.

---

What It Costs*

• Soracom Flux: Free for up to 10,000 events/month on the Developer plan.
• Suspend API: Free, but reactivation fees apply. Use Inactive status for short outages.
• Soracom Peek: One free session per month; $1.00 per session thereafter, plus an additional $0.20 per hour (rounded up to the nearest hour) for sessions exceeding one hour.

*As of June 2026.

---

Takeaway

Auto-suspension protects your bill – but on its own, it throws away the evidence you need to stop the problem from recurring. By letting an Event Handler hand off to a short Flux flow, you can record exactly what the device was doing in the seconds before the SIM goes dark, and turn a recurring mystery into a one-time fix.

---

Looking to capture a more robust image of what data devices are sending? Contact us today to learn how Soracom puts users in control of their data.