[Django]-Is it a bad practice to use sleep() in a web server in production?

Yes, this is bad practice and an anti-pattern. You will tie up the “worker” which is processing this request for an unknown period of time, which will make it unavailable to serve other requests. The classic pattern for web applications is to service a request as-fast-as-possible, as there is generally a fixed or max number of concurrent workers. While this worker is continually sleeping, it’s effectively out of the pool. If multiple requests hit this endpoint, multiple workers are tied up, so the rest of your application will experience a bottleneck. Beyond that, you also have potential issues with database locks or race conditions.

The standard approach to handling your situation is to use a task queue like Celery. Your web-application would tell Celery to initiate the task and then quickly finish with the request logic. Celery would then handle communicating with the 3rd party server. Django works with Celery exceptionally well, and there are many tutorials to help you with this.

If you need to provide information to the end-user, then you can generate a unique ID for the task and poll the result backend for an update by having the client refresh the URL every so often. (I think Celery will automatically generate a guid, but I usually specify one.)

Like most things, short answer: it depends.

Slightly longer answer:
If you’re running it in an environment where you have many (50+ for example) connections to the webserver, all of which are triggering the sleep code, you’re really not going to like the behavior. I would strongly recommend looking at using something like celery/rabbitmq so Django can dump the time delayed part onto something else and then quickly respond with a “task started” message.

If this is production, but you’re the only person hitting the webserver, it still isn’t great design, but if it works, it’s going to be hard to justify the extra complexity of the task queue approach mentioned above.