Project Status Report: Templates, Samples, and How to Write One Fast
A project status report keeps stakeholders informed without a meeting. Here's a reusable template, real samples, and how to automate status reports so you stop writing them manually.
A project status report is a brief, recurring update that tells stakeholders where a project stands. It covers what’s been completed, what’s in progress, what’s coming next, and whether anything is at risk.
Status reports exist to prevent surprises. A stakeholder who receives a weekly status report doesn’t need to chase down a PM to find out why a deadline slipped - they already know, because the risk was flagged in the report before it became a problem.
This guide covers what goes in a status report, a fill-in-the-blank template, real samples for different project types, and how teams are eliminating the manual writing work entirely.
What Is a Project Status Report?
A project status report is a periodic update - usually weekly or bi-weekly - that summarizes:
- What was completed since the last report
- What’s currently in progress
- What’s scheduled to happen next
- Current status (on track, at risk, or blocked)
- Any risks or blockers that need attention
It’s different from a project plan (which describes what will happen) and a retrospective (which looks back at a completed sprint or project). The status report is the ongoing narrative of a project in motion.
Project Status Report Template
Here’s a template that works for most projects. Fill in the blanks and send.
Project Status Report
Project: [Project name] Report Date: [Date] Reporting Period: [Start date] - [End date] Status: [Green / Yellow / Red]
Summary
[2-3 sentences. What happened this week? Are we on track? Any major news?]
Completed This Period
- [Item 1 - link to ticket or doc if relevant]
- [Item 2]
- [Item 3]
In Progress
- [Item 1] - [% complete or current state]
- [Item 2] - [% complete or current state]
Upcoming (Next Period)
- [Item 1]
- [Item 2]
Risks and Blockers
| Risk/Blocker | Impact | Owner | Status |
|---|---|---|---|
| [Description] | High / Med / Low | [Name] | [Open / Mitigated] |
Decisions Needed
[List any decisions that require stakeholder input before the team can proceed. If none, write “None this period.”]
Metrics
| Metric | Target | Actual | Status |
|---|---|---|---|
| [Metric 1] | [Target] | [Actual] | [On track / At risk] |
Project Status Report Color Codes
Most teams use a traffic-light system:
- Green - everything is on track; no intervention needed
- Yellow - one or more risks that could become blockers; watching closely
- Red - blocked or significantly behind; needs immediate attention or decision
The color should reflect the actual state of the project, not how confident the PM feels. A project with a critical dependency on an external vendor that hasn’t responded should be Yellow or Red, not Green because “everything is fine on our end.”
Sample Project Status Reports
Sample 1: Software Feature Launch (Green)
Project: New Onboarding Flow Redesign Report Date: June 22, 2026 Reporting Period: June 16 - June 22 Status: Green
Summary
The redesigned onboarding flow is on track for July 7 beta launch. Engineering completed the core email verification step this week. Design finalized the mobile layouts, which are now in development.
Completed This Period
- Email verification flow - shipped to staging
- Mobile breakpoints defined and handed off
- Copy finalized with marketing
In Progress
- User preferences setup screen - 60% complete
- Integration test coverage - starting this week
Upcoming
- Beta launch to 200 selected users (July 7)
- Internal QA review (June 30)
Risks and Blockers
| Risk/Blocker | Impact | Owner | Status |
|---|---|---|---|
| Analytics tracking not yet scoped | Medium | Jordan | Open - scoping call July 1 |
Decisions Needed
Do we include the optional “import from CSV” step in the beta, or defer to v2? Jordan needs a decision by June 27 to scope it correctly.
Sample 2: IT Infrastructure Project (Yellow)
Project: Database Migration to Cloud Report Date: June 22, 2026 Reporting Period: June 16 - June 22 Status: Yellow
Summary
Migration is progressing but the vendor dependency is introducing risk to the July 31 deadline. The core migration scripts are complete and tested. We are waiting on the vendor to provision the production environment - originally scheduled for June 18, now estimated June 26.
Completed This Period
- Migration scripts written and tested in staging
- Data validation logic complete
- Rollback plan documented
In Progress
- Vendor provisioning (delayed)
- Security review - 80% complete
Upcoming
- Production environment setup (vendor, est. June 26)
- Dry-run migration (June 30)
- Go/no-go review (July 5)
Risks and Blockers
| Risk/Blocker | Impact | Owner | Status |
|---|---|---|---|
| Vendor provisioning delayed 8 days | High | Alex | Open - escalated to vendor account manager |
| Security review finding TBD | Medium | Sam | Open - review completes June 25 |
Decisions Needed
If the vendor environment is not ready by June 26, we will need to discuss either extending the deadline to August 14 or sourcing an alternative provider. Please come prepared to discuss both options at the June 27 project review.
Sample 3: IT Project Status Report (Red)
Project: Legacy System Decommission Report Date: June 22, 2026 Reporting Period: June 16 - June 22 Status: Red
Summary
The project is blocked. The data migration from the legacy system failed validation due to data quality issues not identified in the initial audit. Three weeks of cleanup work are required before we can proceed. The current August 1 deadline is at risk.
Completed This Period
- Initial migration scripts executed (failed validation - see blockers)
- Data quality issues catalogued: 47,000 records with null required fields
In Progress
- Data cleanup script development - starting Monday
Upcoming
- Data cleanup complete (target: July 14 - 3 week estimate)
- Re-validation run (July 16)
Risks and Blockers
| Risk/Blocker | Impact | Owner | Status |
|---|---|---|---|
| Data quality issues require 3 weeks cleanup | High | Taylor | Open - blocking migration |
| August 1 deadline likely unachievable | High | PM | Open - needs stakeholder communication |
Decisions Needed
Recommend revising the project deadline to September 1 to account for the data cleanup work. Need sign-off from project sponsor by June 27 to update the project plan.
IT Project Status Report vs. Standard Status Report
For IT projects, the status report format is largely the same, but with a few additions:
- Change management section - who was affected, what changed, what’s the communication plan
- Security and compliance notes - especially for infrastructure or data projects
- System availability / downtime - any planned or actual service interruptions
- Testing and sign-off - QA status, UAT progress, go-live readiness
IT project leads often send status reports to a broader audience - IT management, compliance, finance - so the language needs to be less technical than a typical software engineering update.
How Frequently to Send Status Reports
This depends on the project phase and stakeholder expectations:
- Active development: Weekly
- Planning phase: Bi-weekly
- Maintenance or monitoring: Monthly
- Crisis or red status: Daily until resolved
When in doubt, more frequent is better. The cost of sending a brief weekly update is low. The cost of a stakeholder discovering a problem through a channel other than your report is high.
How Teams Automate Status Reports
Writing a status report manually takes 20-30 minutes. You open Jira, review what moved this week, pull notes from the last standup, check your Slack for anything you missed, then write a summary in the right format and email it to the right distribution list.
At scale - across multiple projects and multiple stakeholders - this adds up to hours per week of work that has nothing to do with actually moving the project forward.
Telos automates this. It monitors your meetings, Slack channels, and ticket updates continuously. At the end of each week, it generates a draft status report that pulls from all of those sources - completed tickets, meeting discussions, raised risks, upcoming milestones - and formats it for stakeholder review.
The PM reviews and edits the draft in a few minutes, then sends. The research and synthesis is handled automatically.
Ready to stop writing status reports manually? See how Telos automates project reporting. Also useful: the project management automation guide and how to run effective sprint planning.