How to Detect Crypto Market Regime Changes

The problem: Most people watching crypto can tell you the market "feels" risk-on or risk-off right now. That's the easy half. The half that actually changes your day is the flip, the moment the whole market stops being one thing and becomes another. And here's the catch almost nobody plans for: you cannot detect a change from a single look. Knowing the regime now is one job. Knowing it just changed is a completely different job, because a change only exists relative to what came before. Read that part wrong and you build a tool that tells you the weather and calls it a forecast.

What is a crypto market regime change? A crypto market regime is the overall character of the market at a point in time (risk-on, risk-off, broad rally, broad sell-off, large-cap-led, or neutral). A regime change is when that character flips from one state to another between two observations. The current regime is a signal; the change is an event.

Why it matters: You don't rearrange your day because the market is risk-on. You rearrange it because the market just turned risk-on. The transition is the actionable moment, and the transition is the part you can't see in any single snapshot. Detecting it reliably needs memory of the previous state to diff against, which is the piece DIY setups skip first.

Use it when: You're building a crypto alert, automation, or dashboard in Make, Zapier, Dify, or n8n, or driving an AI agent, and you want to be told the market turned instead of staring at numbers trying to feel the turn yourself.

The current regime is a signal. A regime change is an event. Events require state.

Also known as: market regime detection, regime shift detection, market character change, risk-on risk-off flip, crypto regime transition, market state change detection.

Quick answer

• What it is: detecting the moment the whole crypto market flips from one overall character (regime) to another, rather than just reading the current character.
• When to use it: any time you want to react to the market turning, not to a static read of how it looks right now.
• When it doesn't apply: a one-off manual glance at a chart, or trade execution (this is classification, not buy/sell advice).
• The core difficulty: a single snapshot can name the current regime, but detecting the change requires remembering the previous regime and diffing against it. That's cross-run state.
• The main tradeoff: the classification is the visible part, but the memory that turns "what is" into "what changed" is the ongoing cost you either own or hand off.

In this article: What it is · Why the change is the value · Why detecting it is hard · Output example · Alternatives · Best practices · Common mistakes · Limitations · FAQ

Key takeaways

• The one-liner. A snapshot tells you the regime now; only stored state tells you it changed. Reading state is easy, detecting the flip is the hard part.
• The change is the signal, not the state. Knowing the market is risk-on is low value. Knowing it just flipped from neutral to risk-on is the moment you act on.
• Detection needs memory. A regime change is a difference between two observations. With no record of the previous run, a pipeline can name the current regime but physically cannot detect the change.
• Automations branch on a stable enum. A workflow filter can switch on a clean event like market-regime-change with a from -> to. It can't reliably switch on a vibe or a raw percentage.
• Classification is not prediction. A regime label describes observed market data deterministically. It does not forecast where price goes next, and it isn't trading advice.

Regime states at a glance

Reading the left column is a snapshot. Reacting to the right column needs a previous regime to compare against. That comparison is the whole subject of this post.

What is a crypto market regime?

Definition (short version): A crypto market regime is a single classification of the overall character of the market at a point in time, drawn from a fixed set of states like risk-on, risk-off, broad rally, broad sell-off, large-cap-led, and neutral.

It's a way to compress a wall of individual coin moves into one read of the whole market. Instead of scanning fifty percentages and trying to feel a pattern, you get one label that says what the market, as a whole, is doing right now.

A regime is a signal, in the data-to-signals-to-events sense we laid out in the pillar piece. It sits above raw data (the prices and percentage moves) and below events (the changes worth reacting to). The regime answers "what is the market's character?" from one snapshot. It does not, on its own, answer "did that character just change?"

That distinction is the entire point of this article. People conflate the two constantly, and the conflation is exactly why so many crypto tools tell you the temperature and call it a weather alert.

Why is the regime change the thing worth detecting?

The regime change is the thing worth detecting because the transition, not the state, is what you actually act on. A market that's been risk-on for two weeks isn't news. The moment it flips out of risk-on is. You rearrange your day around turns, not around steady conditions.

Think about how you actually use this. If the market has been neutral for days, you're not doing much. The instant it flips to risk-on or risk-off, your whole posture might change: what you watch, what you alert on, whether you tighten or lean in. The static regime is background. The change is the foreground.

This is also why a "current regime" widget on a dashboard gets ignored within a week. It shows you the same label most days, so you stop looking, so you miss the one day it changed, which was the only day it mattered. A regime display trains you to ignore it. A regime change alert only interrupts you when something actually turned, which is the difference between noise and a reason to look.

So the goal isn't "tell me the regime." It's "tell me when the regime changes, and what it changed from and to."

Why is detecting a regime change harder than reading the regime?

Detecting a regime change is harder than reading the regime because a change is defined as a difference between two observations, and a single observation contains only one of them. You can classify the current regime from one snapshot, but you cannot detect a flip without also remembering the previous regime to diff against.

This is the crux, so let me be blunt about the asymmetry.

Reading the current regime is stateless. Hand a tool today's market data and it can classify the whole market into one label. One read is enough. That's why plenty of tools, dashboards, and even a careful human can tell you the regime right now: it only requires the present.

Detecting the change is stateful. To say "the regime flipped from neutral to risk-on," something has to have stored what last run looked like, compared it to now, and noticed the label is different. No previous state, no detectable change. A stateless tool, no matter how good its classification, can tell you what is and is structurally blind to what changed.

And that memory isn't a one-line addition. It's an ongoing job with its own failure modes: storing each run's regime, diffing the new read against the old, deciding what counts as the "previous" state when runs are irregular, handling the very first run when there's nothing to compare against, and keeping a stable, named context so the history actually belongs to the same tracked market over time rather than a different set of coins each run. That's the part that quietly becomes a maintained service. The classification can be reasoned about in an afternoon. The accumulated cross-run memory only exists if you've been running and remembering the whole time, which is why it's the rung DIY setups drop first and notice last.

State is the moat. It's also the reason "just check the regime" and "detect the regime change" are not the same project wearing different hats.

Not all memory is equal: stable state vs stored state

Here's the trap one rung up. Storing the previous regime is the easy half. The hard half is knowing what counts as the same market from one run to the next.

Say you classify the regime off the top 100 coins. If that top 100 is a meaningfully different set today than it was yesterday, you're not comparing like with like, and the "change" you detect might be an artefact of the cohort shifting underneath you, not the market actually turning. Stored state with an unstable basis manufactures regime changes that never happened, and a false flip is arguably worse than a missed one: it trains you to distrust the alert.

So the quality of change detection depends on stable state, not merely stored state. The previous regime has to belong to a consistent, named context that carries across runs, so that a detected flip reflects the market turning rather than the measurement moving. That distinction, stored versus stable, is exactly the kind of thing that looks trivial until run forty, and it's another reason the memory layer is a maintained service rather than a checkbox.

Why do dashboards fail at change detection?

Dashboards fail at change detection because they're built for a different question. A dashboard is optimised to answer "what is true right now?" It shows you the current regime, the current breadth, the current leaders, beautifully. That's a stateless job, and dashboards are excellent at it.

A monitoring system answers a different question: "what changed?" That's a stateful job, and it's the one dashboards are quietly terrible at. A dashboard has no opinion about yesterday; it only ever renders the present. So the burden of noticing that today differs from yesterday falls back on you, the human refreshing the tab, which is exactly the manual triage you were trying to escape. This is the same point we make about decision-first analytics generally: a screen that shows state is not the same as a system that detects change.

What does a regime-change event look like?

A regime-change event is a structured object where the change itself is a stable enum your automation can branch on, carrying the previous regime and the new one. It's not a sentence to parse or a number to threshold. Here's the shape an automation would react to (illustrative values):

{
  "market": {
    "regime": "risk-on",
    "breadth": "broad",
    "health": "healthy",
    "participationQuality": "broad"
  },
  "events": [
    {
      "type": "market-regime-change",
      "from": "neutral",
      "to": "risk-on"
    }
  ],
  "watchlist": {
    "name": "majors-daily",
    "carriedFromLastRun": true
  }
}

Look at what you'd actually switch on in a workflow: events[].type == "market-regime-change", plus the from and to for context. That's a clean branch condition. The watchlist.carriedFromLastRun flag is the quiet tell that state exists at all, that this run had a previous run to diff against. Without that carried state, the events array on a regime flip would simply be empty, because there's nothing to compare to.

This is the difference between an output that says "the market is risk-on" (true every run it's true, and therefore not actionable) and one that says "the market just became risk-on" (true once, exactly when it matters).

How regime-change detection fits the data-to-signals-to-events ladder

Regime-change detection is the clearest single example of the data-to-signals-to-events ladder in action. The raw prices and percentage moves are data. The current regime label is a signal. The market-regime-change event is, well, the event. Same three rungs, one tidy worked example.

The reason it's such a clean illustration is the state requirement is impossible to fudge. With relative strength or a composite score you can sometimes get away with a stateless approximation. With a change you cannot. The event literally does not exist without memory of the prior run, which makes regime-change detection the place where the "events require state" rule stops being abstract and becomes load-bearing.

If you want the full framing of why interpretation, not data, is the expensive part of any monitoring setup, the pillar post covers the whole ladder. This post zooms into the single rung where the state requirement bites hardest.

What detects the regime change for you?

A tool detects the regime change for you by classifying the whole market into a regime on every run and keeping cross-run memory so it can diff this run's regime against the last and emit an event when they differ. The detection is the diff, and the diff needs the stored history.

Stated as a gap: most crypto tools can tell you the regime, few can tell you it changed, because detecting change requires memory, memory requires stable state, and stable state requires persistence across runs. That missing layer is the whole game.

The CoinGecko Crypto Market Intelligence Apify actor (ryanclinton/coingecko-crypto-data) is built to be exactly that layer. On each run it classifies the market into a marketRegime enum (risk-on, risk-off, broad-rally, broad-selloff, large-cap-led, or neutral), alongside market breadth, market health, and participation quality (broad, narrow, or fragile). That's the signal rung, the read of the current character.

The part that matters for change detection: because the actor keeps cross-run state on a named watchlist, it diffs each run's regime against the previous run and emits a market-regime-change event with a from -> to when the regime flips. Your automation branches on that one enum directly, the equivalent of WHERE event = 'market-regime-change', instead of you re-deriving the comparison every run.

It's deterministic. No AI in the classification, no buy/sell advice, no prediction. It classifies observed market data and detects when that classification changed. What you do about the change stays in your workflow, which is where it belongs. CoinGecko gives you the data; this is the layer that tells you the market turned.

What are the alternatives for detecting regime changes?

The alternatives split into a few named approaches. The honest summary: each one either reads the current regime and leaves the change detection to you, or owns the change detection at a cost or in a shape that may not fit an automation.

1. Eyeballing it yourself. A human watches the market and forms an impression of the regime, then notices when it feels different. Best for: a single experienced person watching one market closely with time to spare. Where it breaks: it doesn't scale past one person's attention, it has no audit trail, the "change" is a gut call with no stable from -> to, and you can't wire a feeling into a Make filter. You are the state engine, and you sleep.

2. Raw market-data APIs (CoinGecko, CoinMarketCap, exchange APIs). These serve the underlying numbers cleanly and cheaply. Best for: you only need the data and something downstream does all the interpreting. Where it breaks: there is no regime in the response and certainly no change event. You own the entire classification and the cross-run state engine that turns "what is" into "what changed." That's a maintained service, not a config step.

3. DIY: API plus a store plus your own diff logic. Pull data, classify it into a regime somehow, store each run, and compare. Best for: a tolerance for maintenance and a narrow, stable definition of "regime." Where it breaks: you inherit the classification rules and the state machine, storing every run, defining "previous," handling the cold-start first run, bounding history, and keeping the tracked market stable across runs so the comparison is apples to apples. That's the treadmill, and it's forever, not once.

4. Trading-bot platforms and TA tooling. These can fire on indicator conditions. Best for: execution-focused traders running strategies. Where it diverges: they're built to predict and place orders, the output is tuned for trade execution rather than a clean market-regime-change enum for a Make or Dify branch, and many bundle buy/sell advice you may not want in a monitoring workflow.

5. A classified regime actor with cross-run memory (the CoinGecko Crypto Market Intelligence actor). Classifies the regime each run and emits the change event from stored watchlist state. Best for: recurring crypto automations and dashboards that need to react to the market turning. Where it's not the fit: you want raw numbers only, or you want trade execution.

Each approach has trade-offs in maintenance burden, output shape, and whether it predicts or classifies. The right choice depends on how often you need to react to a turn, whether the consumer is a human or an automation, and whether you want to own the state engine or hand it off. Pricing and features based on publicly available information as of June 2026 and may change.

Best practices for regime-change detection

1. Alert on the change, not the state. Fire your automation on the market-regime-change event, then read the current regime, breadth, and health for context on how loud the alert should be. Don't alert on "regime is risk-on" or you'll alert every run.
2. Branch on the enum, never on a vibe or a float. Build your Make or Zapier logic on the event type and the from -> to. A condition on a stable enum survives; a condition on a raw percentage drifts the moment the market changes character.
3. Run on a schedule, not on demand. A change only exists relative to a previous run, so a one-shot run can't produce one. A recurring schedule is what gives the detection layer something to diff against.
4. Keep a named watchlist. The cross-run memory only accumulates if every run knows it's the same tracked market. Name the set so the regime history belongs to one continuous series.
5. Capture the from and the to. "Regime changed" is half the story. A flip from neutral to risk-on and a flip from broad-rally to risk-off mean very different things. Route on the direction, not just the fact.
6. Model cost before you commit. Use the ApifyForge cost calculator to estimate per-run spend at your schedule frequency.
7. Lock the output shape once. Confirm the exact field and enum your branch depends on with the schema validator so a future change doesn't silently break a downstream filter.
8. Don't rebuild the state engine "to understand it." Understanding why change detection needs memory is useful. Re-implementing the storage, diffing, and cold-start handling is the treadmill this whole post is warning you off.

Common mistakes when detecting regime changes

• Treating the current regime as the alert. A standing read of "risk-on" is true most days and therefore not actionable. If your alert fires on the state instead of the change, you've built a thing people mute in a week.
• Trying to detect a change from one snapshot. A change is a difference across time. With no memory of the last run, your pipeline can name today's regime but physically cannot tell you it flipped. This is the single most common silent failure.
• Ignoring the direction of the flip. Reacting to "regime changed" without reading from -> to throws away the most useful part. Risk-on to risk-off and neutral to broad-rally are not the same event.
• Confusing classification with prediction. A regime label describes observed data. It is not a forecast and not advice. Wiring it straight into an order is a category error this kind of deterministic output isn't built for.
• Letting the tracked set drift between runs. If the market you're classifying is a different set of coins each run, your "change" is partly an artefact of the changing inputs, not a real regime flip. A stable, named watchlist is what keeps the comparison honest.
• Putting prose in the branch condition. If your automation has to parse a sentence to decide what to do, it'll break. Branch on the enum; keep the human-readable summary for the human.

A before-and-after worth showing

Here's a compact, anonymised picture from the kind of monitoring workflow this is built for. First the difference at a glance:

The old way (several times a day):
    Open dashboard. Check the majors. Check breadth. Check BTC dominance.
    "Did the market turn? Maybe. Check again after lunch."

The new way (only when it actually turned):
    10:03   market-regime-change   neutral -> risk-on

One is a recurring chore that depends on you being at the desk. The other is a single line that arrives only when something changed.

Before: An analyst opened a market dashboard a few times a day, scanned the majors and the breadth read, and formed a private impression of whether the market had "turned." Catching an actual regime flip depended on being at the desk at the right moment and remembering what yesterday felt like. Some flips got caught hours late, some got argued over, and there was no clean record of what changed when. Call it a fuzzy, attention-dependent process with no audit trail.

After: The same job runs on a schedule. The regime is classified every run, and the only thing that reaches the analyst is the handful of runs where the regime actually flipped, delivered as a market-regime-change event with a clear from -> to. The analyst stops watching for turns and starts being told about them, with the direction attached. The "did it turn? I think it turned?" guessing collapses into a discrete, timestamped event.

These details reflect one workflow and will vary with how often you run it and how choppy the market is. The shape of the change, from watching-for-the-turn to being-told-about-it, is the consistent part.

Implementation checklist

1. Decide what you're tracking: a fixed watchlist of majors, the broad market, or both.
2. Pick the consumer: a Make scenario, a Zapier zap, a Dify or n8n flow, a dashboard, or an AI agent.
3. Run the CoinGecko Crypto Market Intelligence actor once and inspect the marketRegime field and the events array in the dataset.
4. Confirm the exact event type and from -> to fields your branch will switch on, and lock them in with the schema validator.
5. Put the actor on a schedule so the change-detection layer has previous state to diff against.
6. Add an Apify webhook on run completion to push the regime-change event into Slack, a ticket, or the next workflow step.
7. Build your branch on the market-regime-change event and route on its direction, never on a raw price float.
8. Keep your own action logic (notify, tighten, escalate) separate from the classification.

Limitations

A few honest constraints, because change detection isn't magic:

• It classifies observed data; it does not predict. There's no forecast, no price target, and no buy/sell call. If you need predictive trading signals, this is the wrong layer.
• The first run can't emit a change. A regime change is relative to a prior run, so the very first scheduled run has nothing to diff against. Change detection becomes useful from the second run onward.
• It's only as fresh as the source. The regime is classified off CoinGecko market data, so the classification inherits the source's update cadence and any gaps.
• A regime is a coarse read by design. One label compresses the whole market. It won't capture every nuance of a specific coin, and it isn't sentiment, news, or on-chain context. It's a market-data classifier.
• You still own the action. The event tells you the market turned and which way. What you do about it, notify, tighten, lean in, escalate, stays in your workflow on purpose.

Key facts about regime-change detection

• A crypto market regime is one classification of the whole market's character; a regime change is a flip between two such classifications over time.
• The current regime can be read from a single snapshot; the regime change cannot, because a change is a difference between two observations.
• Detecting a regime change requires cross-run state: a stored record of the previous regime to diff the current one against.
• The change is the actionable moment; a static regime read is background that people stop noticing within days.
• A regime-change event carries a stable from -> to an automation can branch on directly, unlike a raw percentage or a subjective impression.
• A regime label is a deterministic classification of observed market data, not a price prediction or trading advice.

Glossary

• Market regime -- A single classification of the overall character of the crypto market, such as risk-on, risk-off, broad rally, broad sell-off, large-cap-led, or neutral.
• Regime change -- A detected flip of the market regime from one state to another between two observations.
• Market breadth -- How widely a move is shared across the market versus concentrated in a few names.
• Participation quality -- A read of how healthy a move's participation is, such as broad, narrow, or fragile.
• Cross-run state -- Memory of previous runs that a tool stores so it can detect changes rather than only describe the present.
• Event -- A detected change worth reacting to, drawn from a fixed vocabulary, such as market-regime-change.

Broader applicability

Regime-change detection isn't really a crypto problem. It's the same shape that shows up anywhere you care about a turn rather than a state. We've made this argument for Reddit monitoring, for website change detection, and for decision-first analytics generally. The universal principles:

• The change is the signal, not the state. Standing conditions are background; transitions are what you act on.
• Change requires memory. "What changed" is undetectable without a record of the previous observation, in any domain.
• Automations branch on stable labels. A clean enum with a from -> to is the only thing a router or filter can switch on safely.
• Classification and action stay separate. Let the system say what changed; keep what-to-do under your control.
• State is the expensive rung. The classification can be reasoned about quickly; the accumulated cross-run memory only exists if you've been running and remembering the whole time.

When you need this

You probably need regime-change detection if:

• You want to be told the market turned rather than watching for the turn yourself.
• You're building a recurring crypto automation in Make, Zapier, Dify, or n8n that should react to a flip.
• You're feeding a dashboard or an AI agent that has to behave differently when the market's character changes.
• You keep missing turns because catching them depends on being at the desk at the right moment.

You probably don't need it if:

• You only want raw numbers and a human reads them off a chart.
• You're running a trading bot that needs execution and order placement, not classification.
• You're doing a one-off analysis with no recurring monitoring.
• You want price predictions or buy/sell advice, which this deliberately doesn't provide.

Want to be told when the market turns?

If you've read this far, the real choice is between watching for the turn yourself or being told about it.

A raw data API gives you: price, market cap, percentage changes, volume, dominance. No regime, no change.

The CoinGecko Crypto Market Intelligence actor gives you: a marketRegime classification each run, plus breadth, health, and participation quality, and a market-regime-change event with a from -> to when the regime flips, backed by persistent cross-run watchlist memory.

Same source data underneath. The difference is whether you're maintaining the state engine that turns "the regime is X" into "the regime just changed from X to Y," or consuming it. If you'd rather branch on the turn, that's the bridge.

The crypto monitoring cluster

Part of a four-piece set on turning crypto data into something you can act on:

• Data vs Signals vs Events in Crypto Monitoring -- the pillar: the framework this post sits inside.
• Relative Strength vs Price Performance -- the signals rung: why a green number can still be lagging.
• Stop Building Crypto Monitoring Spreadsheets -- why maintaining this layer by hand is a treadmill.

Frequently asked questions

How do you detect a crypto market regime change?

You detect a regime change by classifying the whole market into a regime on each run and comparing the current regime against the previous run's stored regime. If they differ, that's the change. The key requirement is cross-run state: without a record of the previous regime to diff against, a single run can name the current regime but cannot detect that it changed.

What is the difference between a market regime and a regime change?

A market regime is the overall character of the market at one point in time, like risk-on or risk-off. A regime change is the flip from one such character to another between two observations. The regime is a signal you can read from a single snapshot. The change is an event that only exists relative to a previous run, which is why it requires memory and the regime alone does not.

Why can't I detect a regime change from a single snapshot?

Because a change is defined as a difference between two observations, and a single snapshot contains only one. From one read you can classify the current regime, but you have nothing to compare it against. Detecting that the regime flipped needs the previous regime stored somewhere, so the comparison is structurally impossible without cross-run state, no matter how good the classification is.

Does this give me buy or sell signals?

No. The regime classification is deterministic and descriptive: it labels observed market data, it doesn't predict price or recommend trades. A market-regime-change event tells you the market's character just flipped and in which direction. What you do about that, notify, tighten, lean in, escalate, stays in your own workflow by design. Classification and action are kept separate on purpose.

Why do I need to run it on a schedule?

Because a regime change only exists relative to a previous run. A single one-off run can classify the current regime but can't produce a change event, since there's nothing to compare against. Running on a schedule gives the detection layer the prior state it needs, and it lets the named watchlist accumulate a continuous regime history over time.

How does the regime-change event work with Make, Zapier, or Dify?

The change arrives as a stable enum, market-regime-change, with a from and a to, so your scenario branches on it directly. A Make router can switch on the event type, a Zapier filter can gate on it, and a Dify flow can read the from -> to to decide what to do. Because the output is deterministic, the same conditions yield the same event every run, which is exactly what automations and agents need to behave predictably.

Ryan Clinton publishes Apify actors and MCP servers as ryanclinton and builds developer tools at ApifyForge.

Last updated: June 2026

This guide focuses on CoinGecko market data and the Apify platform, but the same change-detection pattern, where a transition matters more than a state and detecting it requires memory, applies broadly to any domain where raw measurements have to drive automated action.