Time tracking & approvals

What this covers

Elliptic has two small, separate systems that both live on a task and both deal with sign-off. Time tracking records how long work took, as worklogs measured in minutes against a work item. Approvals gate a task's move to a new status behind an approver's decision. They are independent: a project can require approval of logged time without using status approvals, and a task can use status approvals without anyone logging a minute. This page walks through both, plus how to export logged time to a spreadsheet.

Both systems are ordinary Elliptic surfaces, which means an agent that is a member of your organization can use them too. An agent can log the time a run took, request a status move and wait for a human to approve it, or sit on the approver side and clear a queue. It operates the same endpoints you do over the company-brain MCP, on your organization's own key.

Logging time

A worklog is a single unit of time you logged against one task, recorded in minutes. Each entry carries the number of minutes, an optional note describing what you worked on, the date it was logged for, and who logged it. Worklogs always belong to a specific work item, so the time you spend is attributed to the task it was spent on, not to a vague bucket.

You log time from inside a task. Open any task to its detail view and find its Time tracking section. There you get a small duration field, an optional note field, and a Log button, followed by the list of entries already recorded on that task.

1. 1
   Open the task

   Open the work item you spent time on and find its Time tracking section.
2. 2
   Enter a duration

   Type how long you spent in the duration field. It accepts 1h 30m, 45m, or a bare number of minutes like 90. The entry must be more than zero and cannot exceed 24 hours (1440 minutes) in a single log.
3. 3
   Add a note (optional)

   Describe what you worked on in the note field. It is optional and can hold up to 2000 characters. You can leave it blank.
4. 4
   Log it

   Press Log (or hit Enter in the duration field). The entry appears in the list and the running total updates. The entry is dated today. The API also accepts an explicit logged_at date if you are backfilling from outside the task UI.

Each task shows a total logged figure above its entries, the sum of every worklog's minutes on that task, formatted as hours and minutes (for example 3h 15m). Individual entries show their own duration, the note (or the logger's name when there is no note), and the date.

You can remove a worklog with the trash icon on its row, but only the person who logged it may delete their own entry. You cannot delete someone else's logged time.

The project total

Beyond the per-task total, Elliptic keeps a per-project total: the sum of all minutes logged across every task in a project. This is what the project's analytics use to show how much time the whole workstream has absorbed. Where a task total answers "how long did this item take", the project total answers "how much time has this project consumed so far".

Worklog approval

By default, time you log is final the moment you log it. A project can instead require that an admin sign off on logged time before it counts. This is a per-project setting, Require worklog approval, and it is off unless an admin turns it on.

When the setting is on, every new worklog on that project's tasks starts in a pending state instead of being immediately approved. Pending and rejected entries are flagged with a badge in the task's time list, so it is always clear which logged time still needs a decision and which was turned down.

Turning approval on

Open the project's settings and find the Time-log approvals section. Flip the switch to require admin approval before logged time on this project counts as final. This switch, and the queue beneath it, are visible only to people who can manage the project (admins). A regular member does not see the approver controls.

The pending queue

While approval is required, the same Time-log approvals section lists every entry awaiting a decision on the project. Each row shows the logged duration, who logged it, and their note, with an approve (check) and a reject (cross) action.

1. 1
   Open the queue

   As a project admin, open the project's settings and find Time-log approvals. Every pending entry on the project is listed there.
2. 2
   Review the entry

   Each row shows the minutes logged, the person who logged them, and the note. Use that to decide whether the time is correct.
3. 3
   Approve or reject

   Click the check to approve the entry or the cross to reject it. Approving marks the time as final. Rejecting marks it rejected. Either way, your account is recorded as the approver, with a timestamp.

A decision records who decided and when, and it removes the entry from the pending queue. The approve and reject endpoints also accept an optional decision note. Approving and rejecting are both admin actions: only someone with admin rights on the project may clear the queue.

Exporting worklogs

You can export a project's logged time as a CSV file, for billing, reporting, or pulling into a spreadsheet. The export is per project and downloads a file named worklogs.csv. From the project's analytics view, the Time log CSV button downloads the full export. To narrow it by date or person, call the export endpoint directly with the filters below.

Each row in the file is one worklog, with these columns:

The export endpoint takes three optional filters, applied independently or together:

• Start date (start_date): only include entries logged on or after this date.
• End date (end_date): only include entries logged on or before this date.
• User (user_id): only include entries logged by one specific person.

With no filters, you get every worklog on the project. Rows come back ordered by date (newest first), then by task number. Cells that begin with a spreadsheet formula character (=, +, -, or @) are neutralized on export, so opening the file in Excel or Sheets cannot execute injected formulas.

# Export one user's logged time for a date range
curl -L -b cookies.txt \
  'https://elliptic.sh/api/orgs/{org_id}/projects/{project_id}/worklogs/export.csv?start_date=2026-06-01&end_date=2026-06-30&user_id={user_id}' \
  -o worklogs.csv

Status-change approvals

Status approvals are a separate system from time tracking. They let you gate a task's move to another status behind an explicit decision. Instead of dragging the task straight into the new column, someone requests the move, and an approver either approves it (which performs the move) or rejects it (which leaves the task where it is).

An approval request is tied to one task and names a target status, the status the requester wants the task to move to. It carries an optional note explaining why, records who requested it, and tracks its own state: pending, approved, or rejected.

You work with status approvals from inside the task. Open the task to its detail view and find the Approvals section. There you can request a move and see every request the task has had, newest first, each tagged with its state.

Requesting a move

1. 1
   Open the task's Approvals section

   Open the work item and find Approvals. If the task has no request in flight, you see a control to request a move.
2. 2
   Pick the target status

   Choose the status you want the task to move to from the Request move to… menu. The task's current status is excluded, since asking to move to where you already are is not a real request.
3. 3
   Request

   Click Request. A pending approval opens for that target status. The request endpoint also accepts an optional note (up to 2000 characters) to explain the move.

Approving and rejecting

A pending request shows approve (check) and reject (cross) actions in the Approvals list. The decision is what actually moves the task, or doesn't:

• Approve marks the request approved and applies the status change, transitioning the task to the requested target status as part of the same action. You do not move the task by hand afterward.
• Reject marks the request rejected and leaves the task exactly where it is. Nothing moves.

Either way, the decider is recorded on the request, the decision endpoints accept an optional note, and the request leaves the pending state. A request that has already been decided cannot be decided again. Past requests stay listed on the task with their final state, so the history of who asked for what and how it was resolved is preserved.