Each updown location host it's own recursive DNS resolver (we use unbound for that) which caches responses accurately by honoring to the TTL configured in your DNS entries. This also means it can cache the absence of record, accoding to the negative TTL present in your SOA record.
By doing so we avoid any dependency on public DNS resolvers and the problems this could add: availability, poor cache retention, increased latency, cache poisoning, incorrect GeoDNS results, etc.
This also means that updown may be more "sensitive" to some DNS migration issues that would otherwise (using a public resolver) be harder to detect. For example let's say you updated an A record with a 1 day TTL (without lowering it first or too late) and the old IP is decomissionned too early (before 1 day). Then it's possible most of your users and yourself will already see the new IP, because the cache in public resolvers would have evicted quickly due to saturation, while updown will still report a downtime for the full 24h until your configured TTL allows our resolvers to pull the new value.
This behavior is correct and intentional (even though you may think your website is working fine) and it's a good way to warn you about dangerous DNS migrations and remind you that in a "worst-case" scenario (if some of your users are using their own DNS professional resolvers for example), they would not be able to access your website.
On the other hand, if you go from a working IP to a non-working one (still with a long TTL), you may get the opposite were public resolvers would show the new IP with the problem earlier while updown will still report UP until the TTL really expires. But that case is less frequent and more importantly, this one is much easier to see for yourself (usually if you change a record you test the new value) so we think it's much more important to show you what you can't see easily.