TL;DR
- Scheduled visibility runs used to fire even when the machine was offline, so a closed laptop meant a run that failed every fetch.
- The app now makes a real connectivity check before a scheduled run starts, because the operating system reports "online" the moment a laptop wakes, before the connection works.
- If the connection dies mid-run, the run stops and the schedule retries once the machine is back online.
- Failed fetches are kept out of your results, so only real answers count.
- Also this week: a finished visibility run can be handed straight to Moose chat for a longer conversation about the results, and audio player customizations now save.
Scheduled to fail
Hi, Moose checks your AI visibility on a schedule: it asks the AI assistants your customers use about your space and records whether you come up. The desktop app does the asking, from your machine.
Which is where the bug lived. The schedule knew when a run was due. It did not know whether the laptop could reach the internet. Close the lid, catch a train, open it somewhere with wifi that hasn't decided about you yet, and a due run would fire anyway, ask every one of its questions into a dead connection, and fail every single fetch. All that work, nothing to show, and a mess for the dashboard to clean up.
A scheduled job that doesn't look up from its checklist is a very relatable failure. It is also a fixable one.
Wifi bars are not the internet
The obvious fix is "check if you're online first", and here is the part that made it interesting: the operating system is an optimist. The moment a laptop wakes from sleep, the wifi interface is up and the OS reports connected, while DNS and routing are still finding their shoes. A run fired in that gap fails exactly like before, with a green wifi icon watching it happen.
So the app stopped asking the OS for its opinion and started checking for itself. Before a scheduled run begins, it makes a real request to two well-known connectivity endpoints, the same kind your laptop uses to detect coffee-shop login pages, and takes the first answer that comes back. No answer from either means no run yet. The schedule simply waits, and the run fires once the connection is real.
Stop, then try again
Connections also die mid-run. The run now notices: if a couple of fetches in a row come back with nothing, it verifies the connection before spending time on the rest. A single check can take minutes to give up on a dead connection, and a run has many of them, so noticing early matters.
If the machine turns out to be offline, the run stops, sets its partial pile of failures aside, and reopens today's schedule window. When you are back online, it fires once and does the job properly. And failed fetches stay out of your results either way, so only real answers count.
A run you can talk to
Also this week: when a visibility run finishes and you want to dig into it, you can hand it to Moose chat for further analysis. The results come along, and because the app wrote that opening prompt itself, chat gets straight to work on it. From a chart to a conversation about the chart, one step.
And a small one that will quietly improve someone's Tuesday: if you customize the embedded audio player for the Listen feature, your settings now save. Set it up once, keep it.
FAQ
What was the bug with scheduled visibility runs?
The schedule fired whether or not the machine could reach the internet. On a closed or freshly woken laptop, the run would start, fail every fetch, and have nothing real to show for it.
How does the app check that it is online now?
It makes a real request to two well-known connectivity endpoints before a scheduled run starts. The operating system's own online flag is not enough, because it reports connected the moment a laptop wakes, before the connection works.
What happens if the connection drops in the middle of a run?
The run stops instead of grinding through the rest of its checks against a dead connection. The schedule reopens, and the run fires once when the machine is back online.
Do failed fetches affect my visibility results?
No. A fetch that never got an answer is reported as unavailable and kept out of your results, so only real answers count.
The one who's under the desk for all of it.
