I think what @traun described is essentially creating your own “heartbeat” by updating a doc that you can then use to trigger a webhook. I don’t believe there’s a way to generate a webhook based on the changes feed heartbeat itself. Traun can correct me if I’m wrong, but I don’t think webhooks provide any real failure handling, so this may not be robust enough for what you want, either.
If I’m understanding your problem correctly, you want to know when a client has been online and synced up all data changes? And you’re saying SG isn’t always up and connected to CBS?
Regardless, for at least part of what I think you’re asking, my inclination would be to have a lightweight service sitting next to SG on the same server monitoring the changes feed. I’m not clear on whether your .NET monitoring service sits on a static IP. If it is, then mini-service could call out to that. (There’s another possibility, namely using Couchbase Server Eventing, which could eliminate the need for another app, but I think that route has other complications.) I’d also look at whether the log output can give you the information you want and consider monitoring that. That could be less heavy-weight than watching a full changes feed.
If neither SG, nor your monitoring service are on static IP, you’re going to have to figure out a discovery/coordination approach yourself first.
Rethinking a bit, something like Traun’s approach seems like a better idea. Update a dedicated “last sync completed timestamp” document. I don’t think I’d monitor this via SG, though, but through CBS itself. This does have a downside of having a window where the client has synced everything but the timestamp document before going offline. At which point your monitor would have the wrong status.