According to the specifications, ULID have milliseconds resolution. Given you are not expecting more than 999 reports within the same second this may be okay.

Timestamp

48 bit integer UNIX-time in milliseconds Won't run out of space 'til the year 10889 AD.

However, if you are running into issues where you need to bucket data in sub-millisecond records; it is possible to devise your own lexicographically sortable timestamp & random value encoding, similar to a ULID, but replacing the randomness by a specific sequence since reading from a good source of randomness may be expensive by itself, at that resolution.

The scheme could take the following form, using a random value read from a sufficiently good source of randomness and an atomic integer sequence:

1. At application start, read R bits from a reliable source of randomness
2. Initialize the atomic integer sequence to 0
3. With each new record to store:
   1. Create an empty byte array
   2. Push the microsecond resolution timestamp into the byte array (with MSB ordering)
   3. Push the random value into the byte array
   4. Push current integer sequence's first N bits at the back of the array
   5. Increment the integer sequence atomically
   6. Encode the byte array into a string; with, for example, the ring containing all letters and digits.

Vary the values of R & N to the desired size. The source of randomness is needed to ensure that records stored from each virtual machine or process does not collide with any other record stored at the same time, during the same sequence.