Blog · May 1, 2026 · ~9 min read

Toggl retainer report: why the built-in “Share” link doesn’t work for clients

Toggl Track ships a feature called Public Report. You filter your time by client tag, click Share, and Toggl gives you a public URL. The URL is free, requires no extra software, and is the obvious first answer to “how do I show my retainer client their hours?” Most freelancers I’ve talked to have tried it. Almost none of them are still using it three months later. The reason isn’t laziness or forgetting — it’s that the Toggl shared report is shaped like a time audit, and a retainer report needs to be shaped like a cycle. The mismatch is small in pixels and large in client behaviour.

What Toggl’s shared report actually shows

Open one. The page that loads is a faithful reproduction of the report you generated in your own Toggl dashboard: a date-range header at the top (e.g. Apr 1 — Apr 30), a total time number (e.g. 14h 27m), an optional pie chart by project, and below that a long list of every time entry — description, start time, duration. It’s well-designed. Toggl’s product team built it for the situation it was built for: here is an audit trail of what I worked on between these two dates. An auditor would love it. A bookkeeper would love it. A retainer client doesn’t love it, because the audit trail is not the question they came with.

The retainer client opens the link with one specific question in mind: am I about to be on the hook for an overage? That question is answered by a single number: hours remaining. The Toggl page does not show that number. It can’t. The page doesn’t know what your retainer cap is. It only knows what dates you queried. So the client lands on the page, sees 14h 27m total, and has to do mental arithmetic: okay, my retainer is 20 hours, so 5h 33m left, I think. That arithmetic is the part where they stop opening the page.

Three structural mismatches with retainers

Drop the cosmetic stuff and the gap is structural. The Toggl shared report and a retainer report are different kinds of object. Three specific places where they diverge:

1. Date range vs. cycle reset

A Toggl report is a date range. You picked Apr 1 to Apr 30 because that’s the range you wanted to look at. Tomorrow you’ll re-share with a different range. The URL doesn’t move with time — it’s frozen at the moment you generated it. If you forget to re-share at the start of May, the public link still shows April’s data, and the client has no way to know that.

A retainer is a cycle. 20 hours per month, resets the 1st. The thing the client wants is the current cycle, always. They don’t want to know which date range you queried; they want today’s burn-down. A static date-range URL fundamentally cannot give them that. It can give them a snapshot of your last query. Snapshots decay; the client opens the snapshot, sees something stale, and downgrades the URL in their head from “reliable status page” to “something Pat sent me one time.”

2. Spreadsheet shape vs. progress-bar shape

The Toggl page leads with a list. Lists are good for completeness; they’re bad for at-a-glance. A retainer status page is a glance product — the whole point is that the client looks at it for three seconds and walks away with the answer. A list of 27 rows is not three seconds of attention.

The right shape for a retainer status page leads with the burn-down number, fat and centered, with a progress bar so the client can see 14 of 20 without reading any numerals. The list is still there — below the fold, for the client who wants the audit trail. But the headline is the cap and the burn, and the audit is the supporting evidence. Toggl’s shared report flips that hierarchy because it was built for the audit case.

3. One report per export vs. one URL per retainer

Every time you re-generate a Toggl shared report, you get a new URL. (Toggl does retain previously-generated reports for a while, but the URL of any given report is the URL of the data at one moment.) That means either (a) you re-send the URL to the client every time you update it, which is the same email loop you started by trying to eliminate, or (b) you trust the client to remember which Toggl URL was the latest, which they don’t.

A retainer URL needs to be one URL per retainer, kept current. The client bookmarks it once. You re-import the CSV; the URL they already bookmarked just updates. The lifecycle of the URL is the lifecycle of the retainer, not the lifecycle of any one CSV export. That’s a different durability contract from what Toggl’s shared report ever promised, and shimming Toggl’s feature into that contract requires either constant re-sending or a third-party layer that handles the “always-current” part.

What the client’s behaviour tells us

The signal is open-rate decay. If you instrument a Toggl shared link (you can’t, but if you could) you’d see the same shape every time: the client opens it twice in the first week — once when you send it, once when they want to check — and then approximately never again, even though they keep emailing you the original question. They’re not lying when they ask. They genuinely don’t remember whether the URL is current, and the cost of opening it and being wrong is higher than the cost of just asking you. So they ask.

This is the same pattern as the underlying billing-vs-status confusion that makes the email recurring in the first place. The client isn’t asking “please tell me a number”; they’re asking “am I about to overspend?” A static date-range page can’t answer that question reliably enough to retire the email. The page lacks the cap (so it can’t express remaining), and it lacks the cycle (so the client can’t trust freshness). Both are required to retire the email; either alone isn’t.

What a Toggl-shaped retainer report should look like

Same Toggl CSV. Different render. Take the Detailed Report export — the same one you’d use for invoicing — and pass it to a layer that knows three things the Toggl shared report doesn’t:

1. The cap — e.g. 20 hours / month. Now “remaining” is computable.
2. The cycle — e.g. resets the 1st of each month. Now “current” is unambiguous.
3. The audience — the client, not you. Now the page leads with the headline number, not the entry list.

That’s the whole spec. The CSV provides the work; the layer provides the framing. The output is one URL per retainer, with a fat 8 hours remain at the top, a progress bar under it, the cycle reset date next to it, and the Toggl entry list below the fold for the client who wants to see what the hours went into.

That’s the shape HourTab’s Toggl integration ships. You drag in the same CSV you already export for invoicing; we map Toggl’s Description, Start date, and Duration columns automatically; you set the cap and the cycle once; you send the URL once. From then on, re-importing a fresh CSV updates the same URL the client already bookmarked. No new link to send. No date-range maintenance. No mental arithmetic on the client’s end.

When the Toggl shared link is the right tool

It’s worth being explicit about when the built-in Toggl shared report is genuinely the better answer, because for some uses it is. If your client is asking for a one-off audit (“send me a list of every entry on the Globex project in Q1 for our finance team”), Toggl’s shared report is exactly right — it’s structured for that use, the URL only needs to live for as long as it takes the auditor to download a copy, and there’s no cycle in the question. Same goes for an annual look-back, or for a one-off project that has a fixed-fee scope and a hard end date with no renewal.

The line is durability. If the URL needs to live as long as the retainer does — and the answer the client wants from it has to stay current the whole time — the shared-report feature isn’t shaped for that job. If the URL only needs to live for an audit window, it’s perfect. Knowing which one you’re building for is the difference between a tool that retires the email and a tool that just adds one more place to look.

The takeaway in one line

The Toggl shared report is a date-range time audit; a retainer report is a cycle-aware burn-down. They look similar at a glance and they answer different questions. If your client keeps asking “how many hours do I have left?” after you sent them the Toggl link, the link isn’t failing them — it was never built to answer that question. The fix is to feed the same Toggl CSV into a layer that was built to answer it, and to give the client one URL with the cap, the cycle, and the burn-down baked in.

If you run Toggl-tracked retainers and you recognize the loop this post is about, you can see how the Toggl-CSV-to-public-URL flow works on the integration page, or read the case for why a public URL beats a client portal regardless of which tracker is upstream. The waitlist on the pricing section is open — free for the first retainer, no credit card — and the only email we’ll send is the one when your first share URL is ready.