Most status reports fail for the same reason: they report activity instead of progress. "We had 14 standups and closed 22 tickets" tells a stakeholder nothing about whether the project is actually on track.
Report against the plan, not the calendar
A good status update always answers three questions: what did we say we would deliver, what did we actually deliver, and what does that mean for the original timeline. If those three things do not line up, say so plainly — stakeholders forgive slippage far more easily than they forgive finding out about it late.
Surface risk before it becomes a delay
The best project leads flag risk a sprint or two before it turns into a missed deadline: a dependency that is running behind, a scope question that has not been answered, a vendor integration that is flakier than expected. By the time a risk shows up as a missed date, it is too late to do anything but explain it.
Keep it short enough to actually get read
A weekly update that takes ninety seconds to read and gets opened every time beats a detailed report that takes ten minutes and gets skimmed once. We aim for one screen: what shipped, what is at risk, what we need from the client this week.