I’m missing some kind of indication when a local monitor is “dead”. Either because the browser was accidentally closed or the computer went to sleep or whatever other reason.
Let’s say I have a monitor configured to run every 5 minutes on a local monitor: I would expect it to either include a “last run” attribute or to be in an error state if it didn’t run for some time (twice the interval might be good enough - ie 10 minutes in my case)
@eyalpost Thanks for the detailed suggestion — this is a valid concern when relying on local monitors.
What’s available today
You can currently verify whether a monitor has been running by checking the Check Log, which shows when the last check was executed:
https://distill.io/docs/web-monitor/how-to-view-log-of-checks/#what-is-check-log
If the browser was closed, the system went to sleep, or the extension became inactive, the Check Log will simply stop updating — that’s the current signal that the local monitor hasn’t been running.
Why local monitors behave this way
This is a known limitation of local monitors:
-
They run entirely inside your browser
-
They stop when the browser closes or the machine sleeps
This is also why Cloud Monitors exist — they run continuously on Distill’s servers and aren’t affected by browser or system state.
Current workaround (if uptime visibility is important)
As a workaround:
-
Create a Cloud Monitor that logs into their Distill account using a Macro
-
Use that monitor to track the Watchlist dashboard itself
-
This gives you a way to confirm whether your local monitors are still updating and visible in the dashboard
While it’s not a built-in health indicator, it can help surface cases where local monitoring has stopped unexpectedly.
At this point, we’re not able to commit to introducing a built-in “inactive / missed run” indicator for local monitors. That said, feedback like yours is genuinely valuable to us.
We closely track feature requests and look at patterns in how customers use Distill—especially thoughtful, real-world workflows like the one you’ve described. If we see similar requests from other users or identify a broader need for stronger visibility around local monitor health, this is absolutely something we would revisit.
Thank you again for taking the time to articulate this so clearly. Even when a request can’t be acted on immediately, it helps guide future product decisions. Please don’t hesitate to share more ideas or feedback as you continue using Distill.
You can currently verify whether a monitor has been running by checking the Check Log, which shows when the last check was executed
If the log was available on web UI then that might work, but logs are available only on the machine where the monitor runs so checking the logs is a bit redundant.
@eyalpost That’s a very fair point — and you’re absolutely right to call out the limitation there.
For local monitors, the Check Log being available only on the device where the monitor runs does make it less useful as a remote or centralized health signal. If the browser is closed or the machine is asleep, there’s no way from the web UI to immediately tell whether a local monitor has silently stopped — other than noticing that updates have stalled.
Why this limitation exists today
Local monitors are intentionally designed to be:
-
Fully browser-based
-
Privacy-preserving (everything runs locally)
-
Independent of Distill’s servers
What does work today (practical options)
If visibility and reliability are important for your workflow, the realistic options right now are:
-
Cloud Monitors
These run continuously on Distill’s infrastructure and always report status in the web UI, regardless of your local machine state. They’re the only monitors today that can guarantee uptime and centralized observability. -
Hybrid workaround (as mentioned earlier)
Using a Cloud Monitor (with a Macro) to watch the Watchlist itself can act as a crude “canary” for local monitor activity. It’s not ideal, but it’s the only way today to remotely infer whether local monitors are still producing updates.
Thank you for pushing on this — it’s thoughtful feedback grounded in real usage, and we genuinely appreciate you taking the time to explain it so clearly.