Blog · May 1, 2026 · ~9 min read

Clockify retainer report: why project estimates and shared report links don’t answer “how many hours do I have left?”

Clockify is the tracker freelancers reach for when they want the bill to be zero. Unlimited users on the free plan, unlimited projects, unlimited time entries, the Detailed Report exports as CSV without a paywall — everything you need to log a retainer’s worth of hours costs nothing. So when the recurring “how many hours do I have left this month?” client email starts arriving, the in-the-box answer Clockify offers is one of two things: set a project Estimate in hours and watch the bar fill, or upgrade and use a shared report URL. Both are reasonable answers to other questions. Neither is the right shape for the client’s glance question, and the email loop runs anyway. Clockify’s retainer story is a project-budget story, not a retainer-cycle story, and the free-tier strength — unlimited client seats — doesn’t resolve the login asymmetry that drives the email.

What Clockify’s built-in retainer tooling actually is

Worth being precise. Clockify, unlike Harvest, doesn’t ship a Retainers tab. There is no first-class “retainer” object in the Clockify data model. What it ships instead, on the free plan, is the Project Estimate field: when you create or edit a project, you can set an Estimate as a number of hours (e.g. 20), choose between fixed and recurring (the recurring toggle landed a few releases back — you can pick weekly, monthly, or custom), and Clockify will compute progress against the estimate as time entries land on the project. The Dashboard tab and the project page both show a fill bar with “X of Y hours” underneath. That’s as close as the free tier gets to a retainer object.

Above the free plan, the Clockify Standard tier ($3.99/user/month at last public list price) adds the “Shared Reports” feature. You build a Detailed, Summary, or Weekly report inside Clockify, configure the date range and project filters, click Share, and Clockify gives you a public URL that renders the report read-only. The URL is the closest analogue to what a retainer client would bookmark. Below that, on the free plan, the equivalent flow is “Export → CSV / PDF / Excel” and email the file — the report exists as a downloaded artefact, not as a URL.

So the in-the-box Clockify answer to “the client wants to see hours remaining” is a stack of three: set the Estimate on the project (free), then either email an exported Detailed Report on the free tier or share a URL on Standard+. All three are documented in Clockify’s help centre under retainer reporting. None of them retire the email.

Three structural mismatches between Clockify’s built-ins and a retainer status page

The cosmetic gap is small — the Estimate field already shows a fill bar, and the shared report URL already serves HTML — but the architectural gap is wide. Clockify’s retainer-adjacent tooling and a retainer status page are different kinds of object. Three specific places where they diverge:

1. Project estimate vs. retainer cycle

The Project Estimate is keyed on a project. Even with the recurring toggle on, what Clockify is modelling is “this project has a recurring budget that resets weekly/monthly,” not “this client has a recurring retainer cap.” That distinction matters in two specific ways. First, a freelancer who structures their Clockify workspace around projects-per-deliverable rather than projects-per-client ends up with the estimate split across three or five project objects per client — one for “Acme · landing redesign,” one for “Acme · ops support,” one for “Acme · SEO advisory” — and the per-project bars don’t aggregate into a single client-level cap unless the freelancer reorganises the workspace around the client. That reorganisation is non-trivial work that loses historical comparability inside Clockify.

Second, even if the freelancer does the work and lands on one project per client, the Estimate still doesn’t model retainer-specific cycle behaviours. Rollover (some retainers carry unused hours forward; some don’t) isn’t a setting on the Estimate. Mid-cycle scope changes (the cap goes from 20 hours to 30 hours starting next month) get applied as a permanent edit, which then back-fills the historical bars with the new number and breaks the audit trail. Cycle-aligned start dates (the retainer started on the 12th of the month, not the 1st) require an explicit recurrence period that Clockify’s recurring toggle doesn’t expose — you get weekly, monthly, or custom-as-fixed-day-count, none of which model “the 12th of each month.” The Estimate is the right shape for a project budget. Retainers are a different shape.

2. Date-range share URL vs. cycle-current page

The Standard-tier Shared Report URL is the closest in-the-box analogue to a public retainer page. A freelancer on Standard can build a Detailed report filtered to the right project, set the date range, click Share, and send the URL. The client opens it and sees the report. So far so good — this is the shape the email loop ought to be a candidate to retire.

The reason it doesn’t retire the loop is that the URL is keyed on the date range you picked when you built the report, not on the current cycle. If you set the report to “This month” on the 3rd, Clockify resolves “this month” at share time and bakes those dates into the URL. Re-open the URL on the 22nd and you’re looking at the same date range from the 3rd, not the cycle the client cares about. (Some Clockify report types do offer a relative-range setting; the persistence of that range through the share URL is inconsistent across report types and tiers, and the safe assumption from the help docs is that the URL is a snapshot of the configuration at the moment Share was clicked.) For the next cycle to be visible, the freelancer has to either build a new report and send a new URL, or reconfigure the existing one and hope the URL still resolves correctly — in either case, the client is back to email or to a stale page.

A retainer status page, by contrast, has to know the cycle definition (e.g. “monthly, resets the 1st”) and recompute “this cycle” on every page load. The URL the client bookmarks doesn’t change between cycles; the contents of the URL move forward with the calendar. That’s a different kind of object: the Shared Report URL is a snapshot stamped with a moment, the retainer URL is a live view of a definition.

3. Free-tier asymmetry: the client login problem the free seats don’t solve

This one is specific to Clockify and is what makes the analysis interesting compared to Harvest or FreshBooks. Clockify’s defining strength is that the free plan has unlimited users. So the obvious-seeming retainer fix is: invite the client as a free user, give them read access to the project, send them the dashboard URL. They log in, they see the project Estimate bar, they see the entries, they get the answer. Cost: zero.

The fix doesn’t take, in practice, for the same reason Bonsai-portal or Plutio-portal fixes don’t take: the client doesn’t want to log into the freelancer’s tooling, regardless of whether the seat is free or paid. Login isn’t a price gate; it’s a UX gate. Each time the client wants to check hours, they have to remember which tool the freelancer uses (every freelancer they work with uses a different one), find the bookmark for that tool’s sign-in page (or wait for a magic link they then have to dig out of email), authenticate, navigate to the project, find the Estimate bar — that’s a five-step path before they see the number. Email is one step. As long as email is fewer steps, email wins.

Worse, the free-Clockify-seat fix puts the client inside the freelancer’s workspace, where they can see (depending on how the freelancer has scoped the access) other clients’ project names, total hours by user, the freelancer’s Dashboard with all clients’ bars at once. Most freelancers don’t want that exposure, so they spend the saved-on-seats time scoping permissions instead, which is admin-shaped work the email loop was supposed to escape from. The free-tier strength turns into an admin tax in this use case, not a saving.

What the client’s behaviour tells us

The signal, again, is the email itself. Clockify-billed retainers produce the same recurring “how many hours do I have left?” email as Harvest-billed retainers, as FreshBooks-billed retainers, as Toggl-billed retainers. Four different tools occupying four different positions in the time-tracking market — the most retainer-aware paid tracker (Harvest), the billing-side tool with a real client portal (FreshBooks), the simple-tracker market leader (Toggl), and now the canonical free-tier tracker (Clockify) — and the email loop runs across all four. That’s as much evidence as you need that the loop isn’t about a missing feature in any one of them. It’s about the shape of the question being a different kind of object than the shape of the data each tool exposes.

The same underlying status-vs-billing confusion sits behind all four cases. The client opens the email at the question moment with one specific need: an answer to “am I about to be on the hook for an overage,” resolvable by one number (hours remaining) on one cycle (this month). Each tracker, including Clockify, has the data to compute that number, and none of them put it on a surface the client can pull at the question moment. So the client falls back to the surface that does answer the question on demand: the freelancer’s inbox.

What a Clockify-shaped retainer status page should look like

Same Clockify data. Different render. The Detailed Report CSV that Clockify already exports on the free tier carries every field that matters — Start Date, Description, Duration (decimal), optionally Project and Client for filtering — and a status-shaped layer adds three things on top:

  1. The cap — e.g. 20 hours / month. Now “remaining” is computable from the entries Clockify already exports. The cap lives in the status layer, not in Clockify, so changes (the cap goes to 30 next month) don’t back-fill historical cycles.
  2. The cycle — e.g. resets the 12th of each month. Now “current” is recomputed at every page load against today’s date, not stamped at share time. The URL the client bookmarks doesn’t need to change when the cycle rolls.
  3. The audience — the client, not the freelancer’s collaborator. No login, no workspace exposure, no Dashboard with other clients on it, no five-step path. One URL, one number, one bar, one cycle reset date, one work log.

That’s the whole spec. Clockify keeps doing what it’s good at — logging hours on unlimited free seats, exporting clean CSV, organising projects across a workspace — and the status page handles the cap, the cycle, and the public-URL audience.

That’s the shape HourTab’s Clockify flow ships. You drag in the same Detailed Report CSV you already export from Clockify (Reports → Detailed → Export → CSV — two clicks, no upgrade), we auto-map the three columns (Start Date, Description, Duration (decimal)), you set the cap and the cycle once, and the URL goes to the client. From then on, re-importing a fresh CSV updates the same URL the client already bookmarked. No client login. No seat to administer. The Clockify free plan keeps doing the tracking, and the status page is the layer the client opens.

When Clockify’s built-in tooling is the right answer

It’s worth being explicit about when the in-box Clockify retainer kit is correct. If your “retainer” is actually a fixed-budget project — “buy 40 hours, work them down, then we re-up” — the Project Estimate models that exactly, and the Standard-tier Shared Report URL with date range “all time” or “since project start” serves the client view well enough. If your client is a heavy Clockify user already (some are, particularly if they’re another freelancer or a small dev shop), the free-seat-plus-project-access flow is fine — they’re going to log into Clockify anyway. If your retainer cycle never moves and you re-build the shared report once a month as part of your closing routine, the snapshot URL is acceptable.

The line is whether the question gets asked between the moments you’d do that admin work. If your client is asking the question on the 14th, the 22nd, the 28th, the email loop will resume by the second cycle of any setup that requires you to re-share a URL or re-grant access to keep it current. Knowing which retainer shape you’re running — project-shaped fixed budget vs. cycling cap — is the difference between a Clockify setup that retires the email and one that adds another tab the client doesn’t open.

The takeaway in one line

Clockify is excellent at the freelancer-side tracking job, especially at the free-tier price point: unlimited seats, unlimited projects, clean CSV export, a usable Project Estimate field for budget bars. None of those answer the client-side glance question, because the Estimate is project-shaped (not cycle-shaped), the Shared Report URL is date-range-shaped (not cycle-current-shaped), and the unlimited-free-seats fix runs into a login asymmetry the price doesn’t change. The retainer client wants one URL, one number, one bar, current as of right now, openable in one step, with no other clients visible. That’s a different object than anything Clockify’s in-box kit produces — not because Clockify is missing the data, but because the question is on the client’s status surface and the kit is on the freelancer’s tracking surface. The fix is to add the status surface, not to wait for the tracking surface to grow into it.

If you bill retainers through Clockify and you recognise the loop this post is about, you can see how the Clockify-CSV-to-public-URL flow works on the integration page, or read the case for why a public URL beats a portal regardless of which tracker is upstream — the per-tracker arc on this blog covers Toggl, Harvest, FreshBooks, and Hubstaff, and the same shape recurs across all five. For a side-by-side of all five, the tracker comparison roundup covers each tool’s built-in client features and the shared gap. 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.