If you're building any kind of SNS automation tool, the fight against bot detection is part of the job. This post is the postmortem of the day Meta's automation detection caught one of the Instagram accounts I was running through my indie SaaS (GramShift), what the actual trigger pattern looked like from the operator side, and the design rewrite I shipped in v1.5.0 as a response.
Note up front: the specific thresholds, probabilities, and timing distributions inside the pacing engine are the product's moat and are intentionally not in this post. The shape of the rewrite is what's interesting; the exact numbers stay private.
What happened
I detect the event from my own logs first, not from Instagram. The like count for a running cycle drops far below the expected band, and the operation log starts emitting action_blocked. I open the affected account in a browser, log in, and the dashboard greets me with:
We're sorry, but we limit how often certain actions can be performed.
This is not a permanent ban. It's a soft cooldown — "we're restricting this account's actions for a while." But if you keep automating through it, the escalation path leads to a permanent ban. I turn off every feature for that account in my tool immediately and let it sit.
Postmortem: it wasn't one thing, it was three things stacking
Sitting down with the two weeks of cycle logs leading up to the event, the picture that emerged was not a single smoking gun. It was three "aggressive" settings stacked on top of each other:
- Cycle intervals too short, and the variance band too narrow. The intervals were random, but the range was tight enough that on aggregate it still looked mechanical to a frequency analysis.
- Daily action total was sitting near the implicit ceiling. Industry chatter puts soft daily ceilings for IG engagement actions in a fairly well-known band. I was running near the top of that band, every day, with no rest days.
- Actions were firing through the middle of the night. A real person sleeps. An account that doesn't is one of the cheapest signals to detect.
Any one of these in isolation is probably survivable. All three at once for two weeks is the kind of pattern that gets flagged. That's the lesson — for this class of tool, individual parameters are less interesting than the interaction between parameters.
The cooldown
Public information on how long the soft cooldown lasts is all over the map — "24 hours to 7 days" is what you'll find quoted. I left the account fully idle for several days, not just my tool but the human-side login too. When I checked back, the warning was gone and the normal feed was back. I assumed (correctly, in hindsight) that the account was likely still under closer monitoring for a while, and dialled the settings way down for the restart.
The rewrite: GramShift v1.5.0 Human-Pacing
Once the dust settled, I rewrote the pacing layer from the ground up. The shape of the rewrite, without the actual numbers:
- Wider, less mechanical interval distribution. Fixed intervals or narrow random bands aggregate into a detectable rhythm. A distribution closer to how humans actually pace themselves is the goal.
- Hard skip at night-time hours. If a human wouldn't be doing this, the tool shouldn't either.
- Per-cycle action count is now variable, with a real ceiling. "Like everything until you hit a wall" is structurally not allowed by the new design.
- Daily cycle count cap. No matter what the per-cycle math says, the day-level total is bounded so the account never drifts toward the implicit ceiling.
The short-term cost of this is real — engagement-driven follower growth gets slower. The trade against the alternative (lost account, lost followers, lost post history) is not close.
The conservative-restart rule
After v1.5.0 shipped, I added an operator-side rule for any new Instagram account being onboarded into the tool: the first two weeks are explicitly under-tuned. Slow mode, follow feature off, daytime hours only, minimum number of cycles. The point is to let Meta classify the account as a "normal user" before any aggressiveness ramps up at all.
Probably the single biggest lesson from this whole thing: for an SNS automation tool, the most important KPI is not engagement efficiency, it's account lifetime. A banned account loses everything you built on top of it. A design that's harder to flag is more valuable than a design that's quicker to grow, in the same way that a slower compiler that produces correct code is more valuable than a fast compiler that produces wrong code.
If you're building anything in this space, I'd argue the right mental model is: you're not optimizing for the next thousand likes, you're optimizing for the account still being alive in a year. Almost every parameter decision flips when you frame it that way.
Curious if anyone else building bot-adjacent automation has done a similar postmortem. The "three aggressive settings stacked" pattern feels like it generalizes well beyond Instagram — same shape is probably hiding in scrapers, API clients, and any other class of tool where a counterparty is doing pattern detection on you.
