Roadmap

Follow the signal.

RefreshRadar is built in the open, and real usage sets the order. Here’s what’s live today, what we’re building next, and the ideas we’re weighing: three stations on one signal path. Step through them.

Live nowBuilding nextExploring
shipped · in production

Live now

Everything below is live in the product today: real and working, not a mockup or a preview.

  • Now live

    Failure & silent-miss detection

    Catches refreshes that hard-fail, get skipped, silently stop running, or get switched off, not just the ones that throw a red error.

  • Now live

    AI root cause, named with the fix

    The moment a refresh fails, RefreshRadar names the likely cause and the fix: a verified catalog answer for common errors, or a live AI diagnosis for novel ones.

  • Now live

    Email & webhook alerts

    The cause and fix land in your inbox, or in a signed webhook you can route to Slack, Teams, or anywhere else, the moment something breaks.

  • Now live

    Every workspace, every client tenant

    One console watching every scheduled refresh across every workspace, and every client tenant you consult for.

  • Now live

    History past the 60-entry cap

    A durable record of every refresh, far past Power BI’s native 60-entry limit. (Free keeps a rolling seven days.)

  • Now live

    Free error catalog & decoder

    A no-login library of Power BI refresh errors: paste yours to get the plain-English cause, the fix steps, and the Microsoft source.

  • Now live

    A live demo, no login

    See the real dashboard catching failures on sample data before you sign up or connect anything.

  • Now live

    In-app help & feature requests

    Ask for help or request a feature right inside the app. Paid plans get priority support.

  • Now live

    Billing that forgives a blip

    A failed card charge keeps your access and history through the retry window, and a missed payment webhook still activates your plan when you return from checkout.

Now live

Failure & silent-miss detection

Catches refreshes that hard-fail, get skipped, silently stop running, or get switched off, not just the ones that throw a red error.

What shipped
Three separate detectors, not one: a refresh that hard-failed, a scheduled slot that came and went with nothing in it, and a schedule that quietly got switched off. The third one also infers why, because Power BI disables a schedule by itself after four consecutive failures, and the only signal is one more email in the model owner’s inbox. Hard failures alert on every plan, free included; the skipped and switched-off checks are part of the paid plans.
What changed
How fast it notices. Paid datasets are now checked twice as often, which takes the worst case from 45 minutes down to 30 on a run where Power BI is not rate-limiting us. Free still gets one check a day, so what it costs to run is unchanged, but that check is now aimed: it lands just after the dataset’s own next scheduled refresh should have finished, instead of at whatever hour the dataset happened to be picked up on. Typical free detection goes from about a day to about an hour and a half. Where the schedule cannot be read, it falls back to a plain daily check rather than skipping the dataset.
Why it’s better
A failure that happened just after a check used to wait for the next one, and on free that could be most of a day. Not because the check ran rarely, but because it was pointed at the wrong time. Same number of checks, aimed properly.
Now live

AI root cause, named with the fix

The moment a refresh fails, RefreshRadar names the likely cause and the fix: a verified catalog answer for common errors, or a live AI diagnosis for novel ones.

What shipped
A catalog of 33 verified errors is consulted first, so a recognised error code returns a sourced cause and fix with no model call at all. Only a genuinely novel error reaches the AI, and the raw Power BI message is redacted before it leaves us. An answer the model is not confident about escalates to a stronger one rather than being served as though it were certain. AI diagnosis of novel errors is a paid capability; the catalog answer is not.
What changed
Two defects in which diagnosis you actually see. Power BI keeps re-serving old refreshes inside its history window, and a re-read of one of those could surface as the headline cause on a newer refresh. Those same re-reads were also taking diagnosis capacity ahead of failures that had only just happened.
Why it’s better
The cause on the screen belongs to the refresh you are looking at, and the failure that just broke your morning gets explained before anything old is looked at again.
Now live

Email & webhook alerts

The cause and fix land in your inbox, or in a signed webhook you can route to Slack, Teams, or anywhere else, the moment something breaks.

What shipped
Exactly two ways out, and a build gate keeps it that way: email, or an HTTPS webhook signed with HMAC SHA256 so you can prove it came from us. The webhook path resolves your URL, checks that every address it got back is a public one, and then hands the connection exactly those addresses, so a hostname that changes its answer between the check and the connection cannot be used to reach inside a private network. Up to ten recipients on an email channel, so alerts reach a team rather than only whoever owns the account. Webhook delivery is paid; email is not.
What changed
A real duplicate, found in production rather than in a test: one Power BI failure was emailing the same person twice, seven days apart. Power BI keeps serving that old failure in its history window, and the record marking it as already reported was being cleaned up on the free seven-day cycle, so the next check treated it as brand new. There is now a small permanent ledger that the cleanup never touches, holding an opaque request id and nothing about the failure itself.
Why it’s better
You hear about a failure once. And the guard that stops the repeat was deliberately checked for the opposite mistake first, because anything that suppresses a duplicate is one wrong condition away from suppressing a real alert.
Now live

Every workspace, every client tenant

One console watching every scheduled refresh across every workspace, and every client tenant you consult for.

What shipped
One account-scoped board that aggregates across every workspace we can see and across each connected tenant, with the tenant boundary enforced in the database rather than in whichever query happens to be running. Watching every workspace is not a paid upgrade: free does it too, and free’s real limit is a dataset count, not a workspace count. Several client tenants on one board is the Team plan.
What changed
A free workspace cap that had been written and tested but never actually switched on was retired instead of enabled. Enforcing it would have contradicted the promise on the front page and would have controlled no cost, because cost follows datasets and checks rather than workspaces. The billing line that said “for one workspace” was strictly false and was corrected at the same time. Separately, a tenant whose workspaces briefly vanished from the Power BI API used to be marked as capped forever; it now takes three consecutive empty reads to conclude anything, and even then monitoring is never switched off on that evidence alone.
Why it’s better
Thin evidence cannot quietly stop us watching a live tenant. Given a choice between going silent and staying noisy through a temporary blind spot, this stays noisy, because a monitor that turns itself off is worse than no monitor.
Now live

History past the 60-entry cap

A durable record of every refresh, far past Power BI’s native 60-entry limit. (Free keeps a rolling seven days.)

What shipped
Every refresh we ingest is kept in our own store, so your record does not end where Power BI’s does. Microsoft keeps between 20 and 60 entries: the newest 60 only while they are all under three days old, and older ones get dropped once there are more than 20. Paid history is unlimited for as long as you are a customer. Free keeps a rolling seven days.
What changed
The order the history was listed in. One check reads a dataset’s whole window and writes it in a single go, so every refresh in that batch shares one arrival time, and the history view was sorting on arrival rather than on when each refresh itself ran. On a dataset you have just connected, where the first check backfills everything at once, that left the list in no meaningful order at all, and “Load older events” could hand back refreshes newer than the ones above it. It now sorts and pages on each refresh’s own start and finish times, the same clock the free seven-day window has always been measured against.
Why it’s better
Your history reads top to bottom in the order things actually happened, and it is right on the day you connect, which is exactly when the whole record lands at once and the old ordering was at its worst. Paging further back stays in order too, instead of jumping around. One consequence worth knowing: a “Load older events” link you had open from before this change starts again from the newest entry rather than resuming mid-history.
Now live

Free error catalog & decoder

A no-login library of Power BI refresh errors: paste yours to get the plain-English cause, the fix steps, and the Microsoft source.

What shipped
33 Power BI refresh errors, each with a plain-English cause, numbered fix steps and a link to the source on Microsoft Learn, plus a decoder you can paste an error string into. It is not a marketing asset bolted on the side: those pages are a projection of the very same catalog the live product uses to diagnose your failures, so what you read for free cannot drift from what the product would tell you. Every source link was resolved live before any of it was published.
What changed
Two entries were giving wrong guidance and were rewritten against Microsoft’s own documentation. One told people to raise a memory property that can only ever lower the ceiling below their capacity limit, so anyone who followed it would have seen nothing improve and reasonably concluded the tool was wrong. The other cited a gateway page that has nothing to do with the privacy-level error it was attached to. A third entry that cites that same gateway page correctly was deliberately left alone.
Why it’s better
A reference that is confidently wrong is worse than one that says nothing, because you act on it, and you do it while something is already broken. These two were checked against the source and corrected rather than quietly left in place.
Now live

A live demo, no login

See the real dashboard catching failures on sample data before you sign up or connect anything.

What shipped
The real dashboard component, rendered on a fictional tenant with a handful of workspaces and datasets sitting in failed, paused, missing and healthy states. It is not a screenshot and not a rebuild: the catalog failures on it are looked up through the same catalog the live product uses, and the remaining one shows what the paid AI diagnosis produces for an error the catalog does not cover.
What changed
Every page in the free error catalog now offers the demo alongside “Start free”. Before that, the only next step from those pages was signing in, which needs consent from a Microsoft tenant admin, so most of the people arriving from a search result or a forum thread hit a wall with nothing else to try.
Why it’s better
You can watch the product do its job before you have to ask anyone at your organization for anything.
Now live

In-app help & feature requests

Ask for help or request a feature right inside the app. Paid plans get priority support.

What shipped
A form inside the app that reaches a person, with a toggle for whether you need help or want to ask for something. Open on every plan, free included. Paid plans carry priority support, described in the app as an aim to reply within 48 hours and deliberately not as a commitment, because one person with a day job should not be selling a response time.
What changed
The daily cap on how many of these could be sent sat above the mail provider’s own daily allowance, so the limit that existed specifically to reserve room for outage emails was reserving none of it. It came down to 25 a day, well inside the allowance, and two rules now hold it there: the per-account limit can never exceed the daily one, and the daily one can never exceed what the provider actually allows.
Why it’s better
Your alerts and the help channel go out through the same mailbox. Asking a question can no longer eat the headroom a failure notification depends on.
Now live

Billing that forgives a blip

A failed card charge keeps your access and history through the retry window, and a missed payment webhook still activates your plan when you return from checkout.

What shipped
Two things that are easy to get wrong about money. A card that fails does not immediately cut your access or start deleting your history: while the charge is still being retried you keep the plan you paid for, and only a payment that has genuinely given up drops you back to free. And if the payment notification from Stripe never arrives, returning from checkout activates the plan anyway, through the very same code the notification would have run.
What changed
The second half of that was built but inert. The route existed, but the address customers were sent back to after checkout still pointed at the dashboard, so nothing ever reached it. Repointing that address and redeploying is what actually switched it on.
Why it’s better
A feature that is built but not wired to anything is worth exactly nothing. This one exists to answer what happens if the payment notification silently breaks, and it only started answering that once the return address changed.
roadmap · demand-driven

Building next

Where our effort is pointed next. Committed direction, no fixed dates.

  • Building

    Solo self-serve setup

    A guided connect for the operator who is their own tenant admin: self-approve the connection and reach a populated board in one sitting, without routing through a separate IT admin.

  • Building

    The rest of Fabric

    Monitoring beyond today’s semantic-model refreshes: data pipelines, warehouses, Dataflows Gen2, and lakehouse / notebook jobs.

  • Building

    Recurring-failure fingerprints

    Collapse every repeat of the same error into one standing diagnosis (“this hit 7× in 30 days”), with the shared cause and fix shown once.

  • Building

    Reliability scorecards

    A screenshot-able health grade per dataset and per account: success rate, typical runtime, and trend over 30 / 60 / 90 days.

  • Building

    Refresh-health digest

    A recurring reliability summary you can forward to leadership (incidents per week, share of clean refreshes), white-labeled on Team.

  • Building

    Chat alert cards for Slack & Teams

    Alerts as a readable card (dataset, error, plain-language cause, fix link) posted natively into Slack or Teams, instead of raw JSON.

  • Building

    AI-drafted support replies

    Faster answers in the help channel: AI drafts a reply grounded in the error catalog, and a human reviews it before it sends. Never auto-sent.

weighing · open

Exploring

Ideas we’re weighing, and genuinely open. Tell us which of these you’d want.

  • Exploring

    Root cause for “completed with warnings”

    Diagnosis for partial successes, where a refresh technically finished but something quietly went wrong.

  • Exploring

    Slow / degrading-refresh alerts

    A heads-up when refreshes start running long or drifting slower, before they tip over into failure.

  • Exploring

    Detection & resolution timing

    How fast issues get caught and cleared, tracked over time, so you can see reliability improving.

  • Exploring

    Quiet hours & maintenance windows

    Mute or schedule alerts around planned downtime, so a known outage doesn’t page you.

  • Exploring

    Public status page & freshness badge

    A shareable, tokenized status page and an embeddable “data is fresh” badge for the dashboards you publish.

  • Exploring

    Team seats & shared boards

    Roles and a shared console for a whole team, not just a single operator.

  • Exploring

    A lighter, sign-in-as-yourself connect

    Skip the tenant-admin step by signing in with your own account. We’re weighing it honestly: keeping always-on monitoring this way means storing a token for your account, which trades against our no-stored-secrets stance. Genuinely open, and we want to know if you’d take that trade.

  • Exploring

    Ran-late / schedule-drift indicator

    Flag refreshes that ran, but not when they were supposed to.

  • Exploring

    Durable-history feed

    Pull your full refresh history into your own tools via a read-only API.

This roadmap is our current thinking, not a commitment or a delivery schedule. What ships next, and when, is shaped by what real users need, so the order changes. “Building next” is where our effort is pointed; “Exploring” is genuinely open.

Shape what’s next

The order here follows what you ask for.

Tell us what would make RefreshRadar a must-have for your Power BI work. The requests we hear most are what we build next.

Start freeEmail a request