Every time Gurobi solves an optimization problem, it produces a log file, i.e. a detailed, chronological record of the solver’s actions and decisions. These logs capture key information about model scaling, presolve reductions, algorithm selection, progress toward optimality, and numerical stability. Reading them effectively allows you to understand how Gurobi “thinks”, diagnose performance issues, and make informed choices about model formulation or parameter tuning.
Numerical Warnings
The first step is to examine the coefficient statistics of your model. Ideally, all ranges —objective, RHS, bound and constraint matrix— should have a width below 1e+06, as explained in Recommended Ranges for Variables and Constraints. Large disparities, especially matrix ranges wider than 1e+09, may indicate poor numerical scaling that can slow down the solver or lead to unreliable results (see What does "Model contains large matrix coefficient range/objective coefficients/rhs/bounds" mean?).
Warning messages in the log often flag potential numerical issues. Thus, pay attention to notices about large ranges, switching to quad precision, tightened Markowitz tolerance, variables dropped from the basis, barrier sub-optimal termination, postponed nodes, or violations exceeding the feasibility tolerance. These messages suggest the solver is compensating for instability and may warrant rescaling or reformulation.
When reformulation is not immediately possible, certain solver parameters can help manage numerical issues:
IntegralityFocus (MIP only)
Cuts (MIP only)
While these parameters may alleviate the symptoms associated with bad numerics, the best long-term solution is to address the root causes directly through proper model scaling and reformulation. For more information, refer to the section Guidelines for Numerical Issues of our Reference Manual.
Presolve
Presolve simplifies the model before solving by removing redundancies and tightening bounds. A strong presolve phase can dramatically reduce the number of rows, columns and nonzeros. Monitoring how much the model shrinks reveals how effectively Gurobi is simplifying the problem and can give an early indication of overall runtime. You can experiment with the parameters Presolve and PrePasses to control the aggressiveness when applying presolve reduction techniques.
LP Solves
For both LPs and the root LP relaxations of MIPs, check how quickly Gurobi finds an optimal solution. Consistent and fast solves typically indicate well-scaled models. Take note of the Method used —primal simplex, dual simplex, or barrier— since Gurobi often runs these algorithms concurrently until the first one finishes. If barrier is chosen, ensure crossover completes in reasonable time; for pure LPs that won't require a basic solution to e.g. perform sensitivity analysis, you can disable Crossover to save computation.
Feasibility & Incumbent Discovery
In MIP models, it’s important to observe when and how Gurobi finds feasible solutions. Early discovery of a first feasible solution enables the solver to apply various heuristic strategies that improve incumbents quickly, often accelerating convergence. Providing an initial feasible solution to Gurobi may help reduce the overall solve time (see our article How Do I Use MIP Starts?)
If Gurobi struggles to find a first feasible solution, consider enabling the No-Relaxation (NoRel) heuristic, which searches for high-quality feasible solutions before solving the root LP relaxation. See How do I use the "No Relaxation" (NoRel) heuristic?
If the NoRel heuristic still fails, try zeroing out the objective, effectively turning the optimization problem into a pure feasibility problem. Alternatively, you can call the method model.FeasRelaxS() to solve a feasibility relaxation, aiming to obtain a solution with a penalty of zero, which would indicate the original model is indeed feasible.
The log also records the origin of each new incumbent: solutions found through heuristics are marked with an H, while those obtained via branching are marked with an *. Understanding this distinction helps diagnose solver behavior, e.g. whether progress primarily comes from heuristic exploration or from systematic Branch-and-Bound (B&B) search. Models that rely heavily on branching may benefit from additional heuristics to accelerate feasibility discovery and improve runtime.
Bound Progress
The Incumbent and BestBd columns in the B&B section represent the primal and dual bounds. If either stagnates for long periods, the solver may be struggling to improve one side of the search. In such a scenario, experiment with different settings of the parameter MIPFocus.
Node Throughput
Node throughput, reported as It/Node, measures the number of simplex iterations per node in the B&B tree search. Efficient models typically show values ranging from a few dozen to a few hundred. Higher counts may indicate numerical difficulties or complex subproblems that slow down the search.