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

    Public status page & freshness badge

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

  • Now live

    Quiet hours & maintenance windows

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

  • Now live

    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.

  • Now live

    Readable alerts in Slack & Teams

    Point an alert webhook at a Slack or Teams channel and get a readable message (dataset, error, plain-language cause) instead of raw JSON.

  • Now live

    Refresh-health digest

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

  • Now live

    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.

  • Now live

    Reliability scorecards

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

  • Now live

    Ran-late / schedule-drift indicator

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

  • 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

Public status page & freshness badge

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

What shipped
One page per connected tenant, at a link only you can mint, showing every monitored dataset with whether it is fresh, needs attention or is paused, and when it last refreshed, plus a small badge you can drop into a README, a wiki or a report footer that says the same thing in a word. Nothing is published until you turn a tenant on, rotating the link revokes the old page at its next request (a badge someone has already embedded can show its last image for up to a minute), and on Team the page carries your own name instead of ours. The status page is part of the paid plans.
What changed
The badge never says "failed". It says "Needs attention", because a public badge that embarrasses the person who published it gets taken down within the week, and then it tells nobody anything. The page carries the detail; the badge carries the invitation to look.
Why it’s better
The states on the public page are the very same states on your own dashboard, computed by the same query, so the page can never claim something your board does not. And the link is the only key: search engines are told to stay out of the page and the badge, and a downgraded or disabled account turns every page off at the next request without a job to run, with an embedded badge following within the minute.
Now live

Quiet hours & maintenance windows

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

What shipped
Per tenant, up to ten windows of two kinds: weekly quiet hours on the days you pick between two local times in a time zone you name (an end at or before the start runs past midnight), and one-off maintenance windows between two dated instants. Anything that fails inside an enabled window is held back from alerting, whatever the channel, and anything that fails after the window ends alerts as it always did. Each window shows how many failures it held back from alerting in the last thirty days, and the whole thing is off until you add a window. Quiet hours are part of the paid plans.
What changed
Where the muting happens. It is not a filter on the alert email: the failure is stamped as muted the moment the alert cycle sees it, before it can be grouped into an incident, and the stamp is permanent, so deleting or shortening a window later never resurrects an alert about an outage you had already declared. And a window mutes alerts only, never detection: the failure still lands on your board, in your history, in your recurring-failure groups and in your reliability grade, because a failure during planned downtime is still a failure that happened.
Why it’s better
You stop paying attention to the alerts you knew were coming, which is the only way the ones you did not know about keep their weight. The time you set is the time it fires on: a weekly window is decided on the wall clock in the zone you chose, so a clock change never shifts the hours you picked, and the count on each window tells you whether it is doing anything at all.
Now live

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.

What shipped
When you send a help request from inside the app and it mentions an error the public catalog covers, the notification that reaches us now carries a suggested reply, written from that catalog entry and nothing else, with a link to the page it came from. A person reads it, edits it, and sends it from their own mailbox, or ignores it. Nothing is ever sent to you by the model.
What changed
It drafts nothing when it has nothing to stand on. A message that names no catalogued error gets no draft, and the notification says so, because a reply invented from a general idea of Power BI is exactly the kind of confident guess this product exists to replace. The same rule already governs every page in the error catalog.
Why it’s better
The draft can only make a reply faster, never wrong on its own: it stays inside the help channel that already has a person at the other end, it is capped by the same limits that protect the alert mailbox, and it is switched off entirely unless we turn it on. You get the answer sooner on the common errors and exactly what you got before on everything else.
Now live

Readable alerts in Slack & Teams

Point an alert webhook at a Slack or Teams channel and get a readable message (dataset, error, plain-language cause) instead of raw JSON.

What shipped
A webhook alert channel can now choose the shape of what we post: the original JSON payload, which stays the default, or a readable message. Paste the incoming webhook URL from a Slack channel or a Teams workflow, pick the readable shape, and failures arrive as something a person can read at a glance rather than a wall of JSON someone has to parse first. The dataset, the error code, the plain-language cause and the fix all come through.
What changed
We did not build a Slack integration and a Teams integration. There is one message shape that both accept, which means nothing to choose wrongly and no second thing to keep working when one of them changes. That turned out to matter sooner than expected: Microsoft is retiring the connector that powered the old style of Teams incoming webhook, and the shape we send is the one its replacement takes.
Why it’s better
Every webhook already set up keeps receiving exactly the bytes it received before, because the original format stays the default and anything unrecognised falls back to it. Turning this on is a choice you make per channel, not a change we make to your integration.
Now live

Refresh-health digest

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

What shipped
A short weekly summary of how your refreshes actually went: how many finished, what share were clean, how many failed, and whether one error accounted for most of them. There is a page in the app showing exactly what it would say right now, rendered the same way the email is, so what you approve is what gets sent. It is off until you turn it on, it goes to the address your failure alerts already use unless you name another, and on Team you can put your own name on it so it forwards internally without ours attached.
What changed
It will not send you an empty one. A period in which no refresh finished produces nothing, because three "all quiet" emails are how you teach someone to stop opening the fourth, and the fourth is the one that matters. That test is on refreshes finished rather than on failures, since a genuinely clean week is worth reporting and a week where nothing ran is not, and they both have zero failures.
Why it’s better
Every number in it comes from the same place as the numbers on your dashboard rather than being worked out again for the email, so a digest cannot quietly disagree with the product when somebody clicks through to check. It also says what it counted, in the body rather than a footer, because a forwarded summary ends up in front of people who were not there.
Now live

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.

What shipped
Your dashboard now leads with how much of what is breaking is the same thing breaking again: each repeating error once, with how many times it hit, how many datasets it touched, when it started and when it last happened, and the cause and fix written out a single time instead of once per incident. It counts over the window your plan retains, and says which window that is, so free gets this too rather than being locked out. The AI reading of a novel error stays a paid capability; the count and the catalog answer do not.
What changed
Two failures count as the same failure only when they share an error code, which is already the identity Power BI errors are keyed by throughout the product. Grouping on the message text or the broad category would have caught more repeats, and would have been worse: it merges genuinely different faults under one confident heading, and a standing diagnosis is precisely where that misleads, because it tells you one fix covers several incidents. Failures that arrive with no error code are counted and reported on their own rather than folded in.
Why it’s better
A board with the same credential error on eleven rows reads as eleven problems. It is one problem, and the useful number is that it has happened eleven times, is spreading across datasets, and started three weeks ago. The card also shows what it could not group and why, so the total it reports is one you can reconcile against the board rather than take on trust.
Now live

Reliability scorecards

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

What shipped
A letter grade on your dashboard and on each dataset, over the last 30, 60 and 90 days, with the success rate and the exact number of refreshes it came from printed next to it. Beside the grade sits the typical run time and the slowest five percent, because a median on its own hides the long tail, and the long tail is what actually breaks whatever runs downstream. Grades are built on durable history, so free keeps a rolling seven days and the card says that plainly instead of grading a shorter window and calling it 30 days.
What changed
What counts toward a grade ended up narrower than the obvious answer. Only completed and failed refreshes are scored. A refresh someone cancelled is left out, because counting it as a failure would be grading your own decision to stop it, and one that never ran because its schedule was switched off is left out too, since nothing was attempted. Anything Power BI reports that we do not recognise is excluded rather than guessed at, so a status they add later cannot quietly move everyone’s grade overnight.
Why it’s better
A number you cannot check is worth nothing. So every grade shows the denominator it was calculated from, and the card states what it excluded rather than burying it. Below ten finished refreshes in a window there is no letter at all, just the real tally, because a letter derived from three refreshes implies a confidence the data does not carry.
Now live

Ran-late / schedule-drift indicator

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

What shipped
Every scheduled refresh that ran is measured against the slot it was supposed to run in. Each dataset shows how many of its scheduled runs started on time, how many started late, the median and the worst delay with the slot it belonged to, and, on the paid plans that keep the earlier period, whether the median is moving later than it was. The dashboard lists only the datasets that ran late in the last thirty days (seven on free, the history it keeps), and every late run in that window is tagged in the refresh history with its delay. Nothing here alerts: a run that never happened at all is what silent-miss detection is for.
What changed
Two definitions had to be pinned before a single number could be shown. Late means the run started more than fifteen minutes after its slot; inside that, the scheduler is doing its job. A run that starts more than an hour after its slot is counted as outside any scheduled window rather than merely late, because by then the slot itself was missed and the run is a different kind of news. And whether Power BI applies daylight-saving time to a schedule is still unsettled, so a slot has two possible readings an hour apart: a delay is measured from the nearer reading the run could actually have followed, and the hour of tolerance runs from the later one, never adding an hour we cannot prove. The first cut got that hedge wrong in one band and read some late runs as early; an adversarial pass caught it before it shipped.
Why it’s better
A green history hides a refresh that finished at nine when the report was due at seven. "It ran" and "it ran when people needed it" are different facts, and only the second one is what a stakeholder feels. Stating the fifteen-minute rule and the time zone on the card means the number can be argued with, which is the only kind of number worth showing.
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.

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

    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

    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