---
title: "Status report template – Display.dev"
description: "A weekly status report in plain Markdown – TL;DR, progress, slips, the numbers that matter, and risks. Publish it to a URL in one click, no account."
---

# Status report template

A weekly status report in plain Markdown – TL;DR, progress, slips, the numbers that matter, and risks. Publish it to a URL in one click, no account.

- Format: Markdown
- Detail page: https://display.dev/templates/status-report
- Raw template file: https://display.dev/template-sources/status-report.md
- One-click anonymous publish (no account): POST the file to https://api.display.dev/v1/public/artifacts as multipart/form-data (`file` field)

## Agent prompt

Publish a status report for this project on display.dev. Fetch the structure from https://display.dev/template-sources/status-report.md and keep its sections: TL;DR, progress this week, slipped or blocked, a numbers table, next week, risks. Fill every section from the project's actual state – real dates, real metrics, no placeholders.

Publish it with the display.dev MCP publish tool if connected. Otherwise POST the file to https://api.display.dev/v1/public/artifacts as multipart/form-data (`file` field, optional `name`) – no account needed. You'll get back `previewUrl` (the link to share) and `claimUrl` (one-shot link to take ownership). Reply with both.

## What this template is for

The weekly update your team actually reads. One page: what moved, what
slipped, the four metrics that matter, and the risks worth naming. The
TL;DR at the top means a skimming manager gets the state in ten seconds;
the table means nobody asks "what's the error rate now?" in standup.

It's plain Markdown, so it works everywhere Markdown works – and it's the
format an agent can fill in from your repo, your tracker, or your metrics
warehouse without any special tooling.

## How teams use it

- **Written by an agent, reviewed by the owner.** Point your agent at the
  repo and the numbers, let it draft the report, then edit the risks
  section – that's the part that needs human judgment.
- **Published weekly at the same URL.** Publish updates as new versions on
  display.dev and the link you shared in Slack keeps showing the current
  week.
- **Gated when it matters.** Numbers like error rates and conversion
  belong behind your company's Google or Microsoft sign-in, not on a
  public link.

## Template source

````markdown
# Checkout service – status report

**Week of 20–24 July 2026** · Owner: Priya N. · Status: **On track**

> **TL;DR:** Payment-retry rollout reached 100% of traffic on Tuesday with no
> error-rate movement. Refund latency work slipped one week – blocked on the
> ledger migration. Nothing needs a decision this week.

## Progress this week

- Payment-retry rollout completed: 25% → 100% of traffic, error rate flat at
  0.04% (was 0.05% before rollout).
- Idempotency-key handling shipped for the `POST /charges` path; duplicate
  charge reports dropped to zero since Wednesday.
- Load test at 2× peak traffic passed – p99 held at 180 ms.

## Slipped or blocked

- **Refund latency (was: due 24 Jul, now: 31 Jul).** The fix depends on the
  ledger migration, which is still replaying historical events. No customer
  impact meanwhile – refunds complete, just in 4–6 h instead of the 1 h
  target.

## Numbers that matter

| Metric | Last week | This week | Target |
|---|---|---|---|
| Charge error rate | 0.05% | 0.04% | Below 0.1% |
| p99 charge latency | 210 ms | 180 ms | Below 250 ms |
| Duplicate-charge reports | 3 | 0 | 0 |
| Refund completion time | 4–6 h | 4–6 h | Under 1 h |

## Next week

- Land the ledger migration and unblock refund latency.
- Start the chargeback-webhook spike (2-day timebox, decision doc to follow).

## Risks

- Ledger replay is single-threaded; if it runs past Tuesday, refund work
  slips a second week. Mitigation: replay is resumable, and we can shard it
  by account range if Monday's checkpoint looks slow.
````