Does PRTG have a catch-up function?

Unfortunately at this time there is no way to do this directly with PRTG. Messages cannot be pushed into the DB with a different time stamp from when they are received. When data is received by the PRTG core, it is time-stamped at the point and this cannot be changed.

In your case though, if you had a remote probe on the target device itself, when it was disconnected, it could collect this data and then send it to PRTG with the correct time-stamps. Is this something that could work for you?

I'm afraid I can't use the PRTG Remote probe. It is Windows CE devices that I am monitoring. These devices doesn't support the Remote probes, and is very limited in memory as well. I was hoping to collect data in XML files (or so), and let a custom sensor import the logged values from the files once the connection came to live again...

Please note this as a request for new functionality. It's a grate wish in the company I'm working for.

Thanks.

I'll change this article to a feature request and anyone who sees this article can comment here and we will consider that to be another vote for this feature. We do have the HTTP push sensor where you can push information to the PRTG server but unfortunately when the data is pushed it will be timestamped so there is no way to backfill data like you mention here.

Would it be possible to create a PRTG Mini Probe and install it on the Windows CE device, and get catch-up functionality this way?

At this time, the mini-probes don't have a buffer for the sensor results so this wouldn't give you the desired result.

Really? My bad then. I just figured it had because the API for the mini probe included a GMT timestamp... Then what is the timestamp used for? If not to state when the data was logged?

The timestamp is included for when PRTG stores the data in the database. Each record stored in the PRTG database must include the timestamp for the reporting / graphing to work properly. At this time, there is no way for the mini-probe to initiate a scan since it waits for the request from the core. When the core is unable to send out the request to the mini-probe, it won't initialize a scan on it's own. We will look into this and see if it may be possible to have the mini-probe initiate the scan itself when there isn't a core connection and then store the results in a buffer that can then be sent when the core connection is alive again but it will probably take a while before we can implement this.

After speaking with the Mini-Probe developers they said that it's likely possible to build something like a buffer into the mini-probes but that the API isn't really designed for it. You can try implementing this yourself but for the foreseeable future it's not something we want to put into the mini-probes.