Scheduling and hours
Set a time once and the log is drafted every night. This page is the fine print: what a schedule means, what a run costs, and what an hours figure is allowed to claim.
Time is wall-clock where you are
A schedule stores an IANA zone alongside its HH:MM. 22:00 means 22:00 in Kolkata if that is your zone, and a commit at 01:00 IST belongs to that day's log, not the previous one. There is no “local” fallback that reads the server's clock, because the server is in UTC and reading it is exactly what puts a late commit on the wrong day.
The zone is resolved in this order: what your browser sent with the request, then the zone stored on the schedule, then UTC. Enabling a schedule without a zone is refused rather than defaulted.
Three ways it fires
| Trigger | When to use it |
|---|---|
| Built-in scheduler | The server sweeps every enabled schedule every five minutes, on its own. On whenever the service role key is set — this is how the hosted service runs. Turn it off with DEVLOG_BUILTIN_SCHEDULER=off if you prefer cron. |
| External cron | The same sweep, fired from outside with the cron secret. For hosts that put the server to sleep between requests. |
| In-app runner | Polls every minute while a Devlog tab is open. The only trigger on a server with no service role key. |
curl -X POST https://devlog.app/api/scheduler -H "x-cron-secret: $CRON_SECRET"
A day with nothing to log — no commits, or already written — counts as done, and the schedule moves on to tomorrow. A failed attempt is retried after thirty minutes, not every minute, and the Automation page shows the next run, the last attempt and its error. Every run records what it wrote, what it skipped, and what it cost.
Review before write
The automation console and bulk fill both do a dry run first: summaries are generated without writing, billing or recording a run. You read them, edit anything that misreads the day, drop days you don't want, and only the approved set is persisted. A scheduled nightly run drafts entries the same way and leaves them for you to approve in Daily Work.
Back-filling a range
Bulk fill takes a date range and fills every day that has activity and no entry yet. Days already logged are left alone. Preview one day first shows what the model will produce before you commit to the whole range.
Where an hours figure comes from
Every entry records the provenance of its hours, because that number lands on a timesheet:
| Provenance | Meaning |
|---|---|
| measured | The span between the day's first and last commit, plus hours logged against activities. |
| typed | You entered it. Editing hours anywhere sets this. |
| estimated | The model's guess. Labelled as an estimate everywhere it appears, never as a measurement. |
Credits
Generation through Devlog's own pipeline costs 1.5 credits per commit, charged only for days that actually produced an entry. Skipped and failed days cost nothing. A run refuses up front when its estimated cost exceeds the balance rather than generating everything and then clamping the deduction.
Your provider bills the model calls to your own key; credits pay for Devlog's pipeline. In a workspace, runs draw on the team's shared pool first and your own balance after it; individuals can buy packs from Billing.