@mhfs I just checked Sidekiq code. Seems like your solution is viable. However they way Sidekiq process scheduled jobs sound a bit strange to me. When a scheduled job is created it passes all client middlewares within the ruby process calling perform_at/in and then the same ruby process adds the job to 'schedule' redis sorted set. 

Then sidekiq "server" ruby process polls this sorted set periodically and as soon as it finds the job which is due to run it calls Sidekiq::Client.push(msg) which invokes all client middleware chain, but within sidekiq "server" process. 

So SidekiqStatus::ClientMiddleware is effectively invoked twice. So with your solution to the problem SidekiqStatus::Container is created on the second invokation when job arguments do not include 'at' key.

The fact that this works looks a little brittle to me. As soon as Sidekiq begins to handle scheduled jobs differently this code will break.

So I am going to merge your PR now. But I ask you to kindly add more extensive tests to cover all this behavior. An integration test should be enough