The developer diary stack: GitHub, Slack, Todoist, Toggl
Most of a developer’s working hours leave a trail somewhere. The commit lands in version control. The decision lands in a Slack thread. The task gets ticked off in a list manager. The hours land on a tracker. Four trails, four different systems, and no single one of them tells the story of a day.
A developer journal needs the four together. One alone is a code log, or a chat dump, or a checklist, or a timesheet. None of those is a journal of the day you actually had.
deariary connects to all four: GitHub, Slack, Todoist, and Toggl Track. The deep-dive posts cover what each integration captures in isolation. This one is what running all four at once actually produces.
Four layers, almost no overlap
The reason these four work as a stack is that each captures a dimension of the workday the others miss.
GitHub captures the output. Commits, pull requests, reviews, issue comments. The artifacts that land in version control. This is the record that survives the longest, but it is also the most stripped down: a commit message tells you what changed, not why you chose that approach over the two you discarded first.
Slack captures the conversation. Threads in #backend, DMs from a teammate stuck on a deploy, the architecture debate you mediated before lunch. Slack holds the reasoning that does not fit in a commit message. It is also the only system that captures the work you did without producing code: the explanation you wrote, the question you answered, the off-the-cuff design sketch that ended up shaping someone else’s PR.
Todoist captures the intent. What you planned to do this morning. Which tasks you actually closed. Which ones slipped to tomorrow. The commit log shows what landed; the task list shows what you set out to land. The gap between the two is often the most interesting part of the day.
Toggl Track captures the cost. The other three layers describe what happened. Only the tracker says how much of your day each thing actually took: the four hours behind a one-line fix, the thirty-minute admin item that should have taken five, the long lunch that explains a quiet stretch in the middle of the afternoon.
These four layers are not interchangeable. The code log without the conversation drops the reasoning. The task list without time tracking drops the actual cost. The time tracker without GitHub drops the artifacts. Each layer fills a gap the others leave open, and the workday has all four kinds of gap.
How a stacked day reads
A Tuesday with all four connected might produce raw data that looks like:
09:10 Timer: "Backlog triage" (40m)
Todoist: Closed 4 stale tickets, moved 2 to next sprint
09:50 Timer: "Search ranking regression" (1h 50m)
GitHub: Pushed 3 commits to search-service, opened draft PR #1209
11:40 Slack: Thread in #data with @maria about index freshness (8 messages)
12:30 Lunch
13:30 Timer: "Search ranking regression" (2h 05m)
GitHub: PR #1209 marked ready, addressed two review comments
Todoist: Completed "Investigate search ranking drop"
15:35 Slack: DM thread with onboarding hire about test fixtures (12 messages)
Todoist: Did NOT complete "Refactor invoice generator helpers"
16:30 Timer: "Code review: billing dashboard" (50m)
GitHub: Reviewed PR #1184, left 5 comments and requested changes
17:20 Slack: Posted weekly progress note in #search-teamdeariary weaves it into something like:
Tuesday opened with a quick triage block: four stale tickets closed and a couple bumped into the next sprint. From there the morning collapsed into the search ranking regression that Monday had ended on. Most of an hour and fifty minutes went to it before lunch, with three commits pushed to search-service and a draft PR opened. Maria pinged you in #data midway through about whether the index freshness window was the cause, and the thread settled on a yes.
After lunch, two more hours on the same regression. The PR went out of draft, you addressed the two comments that came back quickly, and the ticket finally closed. About four hours, end to end, on something Monday assumed would take an afternoon.
The invoice generator refactor that was supposed to fit somewhere in the day did not. It rolls into Wednesday. Late afternoon turned into a longer DM thread with the new hire about how the test fixtures are organized, then a fifty-minute pass through the billing dashboard PR before logging off with the weekly note in #search-team.
One Tuesday. The tracker supplies the cadence. GitHub supplies the artifacts. Todoist supplies the intent and the slip. Slack supplies the reasoning that does not fit anywhere else.
Six months from now, reading this Tuesday back, the four layers do different work. PR #1209 is the part you can still find in the repo, but the diary is what tells you why almost the entire day went to it. Maria’s thread explains why the fix targeted the index freshness window and not the ranker itself. The unfinished invoice refactor is the reason Wednesday began where it did. The four-hour total from the tracker is the figure that, without the layer, would have shrunk in memory to “I spent most of Tuesday on the search bug” without the precision that makes the memory useful.
A code-only entry would say “merged a webhook fix and reviewed three PRs.” A task-only entry would say “closed one task, missed one.” A time-only entry would say “tracked seven hours across four projects.” The stacked entry says what the day was.
When the layers intersect
Most of the time the four cover different ground. Where they overlap, the overlaps are the most legible parts of the diary.
A task and a PR for the same thing. Todoist marks “Investigate search ranking drop” as complete; GitHub records the PR that fixed it. The diary connects the planned work to the artifact, so the entry reads “the ranking investigation closed with PR #1209” instead of two unrelated facts.
A Slack thread and a commit on the same topic. A debate in #data about index freshness followed by a fix that targets exactly that. The thread is the decision; the PR is the consequence. Reading the entry months later, the order makes the rationale obvious.
A tracked block and a task that did not land. The tracker shows two hours on “Queue migration design doc”; Todoist shows the task incomplete. The pair tells you the work happened, the artifact did not yet land, and the time was real. A time-only entry would call the day productive; a task-only entry would call it unfinished. The pair calls it what it actually was: a long thinking session that has not produced its output yet.
A morning with no Slack and a heavy commit log. Toggl shows three deep-work blocks, GitHub shows seven commits, Slack and Todoist are quiet. A focus morning. The diary reads like a focus morning, and the absence of the other two layers is the signal.
The intent-vs-output gap
One pairing inside the stack deserves its own note. Todoist and GitHub together do something neither does alone: they make the gap between what you intended and what you produced visible inside the diary.
Some days the two match. The tasks you set in the morning are the PRs you merge by evening. The diary reads tidy, and that is part of the record.
Most days the two do not match. A scheduled task slips because a production issue surfaced and ate the afternoon. A PR landed that was not on any list, because a teammate asked for a quick fix and you took it. The morning’s plan turned out to be wrong by 11 AM. None of these are failures. They are the actual texture of how engineering work happens, and they are invisible in either system alone. Todoist will quietly carry the unfinished task forward. GitHub will quietly record the unplanned PR. Only the diary, with both layers, shows the trade.
Reading these gaps back over a quarter, patterns appear. Some weeks the slips cluster on Fridays. Some sprints have a recurring theme of unplanned hot-fix PRs that point to a fragile area of the codebase. The patterns are not in any tool. They emerge once the intent layer and the output layer sit next to each other on the page.
Plan requirements
The Free plan caps you at one connected integration. That is fine for trying any of the four on its own. Running the full developer stack needs the Basic plan or above, which raises the cap to five and leaves a slot open for whatever else fits the role: a calendar for managers, a Bluesky connection for the build-in-public crowd, or any of the other live integrations. See deariary.com for the current pricing.
Order to connect them in
Connecting all four takes a few minutes total. GitHub OAuth is the longest of the four; the rest are token paste or OAuth flows that finish quickly.
A reasonable order is GitHub first, then time tracking, then Todoist, then Slack.
GitHub first, because its artifacts are the densest on their own. A GitHub-only diary is already a useful record of the day’s output, so the value of running automatically appears in the very first entry.
Time tracking second, because it answers a question GitHub cannot: where did the hours go. On a day with two commits and seven hours on the clock, the tracker is the only system that explains the gap between what shipped and what the day was.
Todoist third, because it adds intent. With code and time alone, the diary already records what you produced and how long it took. Todoist adds what you planned to produce, and the gap between intent and output starts showing up.
Slack last, because the work it requires from you is choosing the right channels. That choice is easier after a few weeks of entries make it obvious which conversations carry weight.
The next morning after each connection, the entry incorporates whichever of the four had activity. On a meeting-heavy day with no commits, the entry leans on Slack and Todoist. On a heads-down debugging day with no Slack, it leans on the code and time layers. The stack adapts to the kind of day it is reporting.
Where the stack stops
The four together do not cover everything a developer does. Calendar meetings are absent unless you add a Google Calendar connection (useful for managers and leads more than for individual contributors). Repositories outside GitHub are absent. Documentation written in Notion or Confluence is absent. Whiteboard sessions, hallway conversations, the thirty seconds of insight in the shower: none of those land in any tool, and so none land in the diary.
For meetings, alternative repos, or shared docs, additional integrations or a webhook bridge can fill some of the remaining gaps until native support exists.
What the four-tool stack does cover is the core of how a working day in software actually unfolds: the code that landed, the conversations that shaped it, the tasks that drove the day, and the hours the four added up to. For most developers most of the time, that is most of the workday, and the four together produce something none of them produces alone: a developer journal that reads like the work, not like four separate logs stacked on top of each other.
