Session overage time calculations?

Answered

Chris Raymond-Bertrand

December 01, 2025 15:16

• 

Hello, 

I am a university user under the WLS Academic license, running jobs on our school's compute cluster. Most of the time, when running 2-3 jobs in parallel no issues occur, but periodically I get error 10030: Overage for too long, 3 active sessions and over the baseline for 32 minutes. My license says I have a max baseline of 2 active sessions, but I have not had any issues running 3 jobs in parallel outside of 1-2 errors over the course of the past few months. However sometimes when starting jobs too close to each other (starting two jobs, canceling them both, then quickly restarting them) I get this overage issue, even when only running 2 at once which seemingly should be okay. 

This leads me to being confused as to how the overage is calculated. The error message is decently clear, I had 3 sessions active for 32 minutes, when I am only allowed 2. However, as described above, this isn't really what I am observing. Is there anything I can do to avoid encountering this error? My supervisor suggested something to do with tokens, but they seem to be properly released and expire as expected. Otherwise, is there a formal process to request an increase in the active sessions baseline?

Thank you,

Chris.

Related to

• Academic License
• Error
• WLS (Web License Service)

0

• 

  Adam DeJans Jr.

  • Gurobi Staff

  December 02, 2025 15:30

  Hi Chris,

  Thanks for the detailed explanation. What you’re observing actually lines up with how the Web License Service (WLS) handles session usage.

  According to our documentation here: How do I resolve the error "Overage for too long"?

  WLS evaluates usage based on active sessions, and a session continues to count against your baseline until:

  1. The Gurobi environment is closed, and
  2. The token’s lifespan expires (the default minimum is 5 minutes).

  This means even after a short job finishes (or if you cancel a job) the session remains “active” for up to 5 minutes while the token ages out. When you rapidly start, cancel, and restart jobs, the older sessions may still be counted. This can produce brief periods where WLS sees 3 active sessions, even though you may think only 1–2 jobs are running.

  If these overlaps persist across several 5-minute windows, WLS reports something like the error you see: “Overage for too long, 3 active sessions and over the baseline for 32 minutes.” 

  This explains why short jobs or tightly restarted jobs trigger the error even though your baseline allows 2 sessions. To avoid this behavior make sure environments are explicitly closed so tokens begin expiring immediately and stagger job launches on your cluster so restarts don’t overlap in the same 5-minute windows.

  If your workflow requires 3 active sessions consistently, please feel free to contact our licensing team or open a support ticket. We can review your case and help determine whether an additional license or an adjusted setup is appropriate for your needs.

  Let me know if you have any other questions!

  2

Please sign in to leave a comment.