The Morning Routine Problem and the Workflow That Actually Fixed It
It started with a comment in a client Slack at half past eight on a Wednesday. Someone had pinged the wrong channel, a support message had gone unread for six hours, and the reason it went unread was that I was checking five different places in a sequence that I had somehow convinced myself was a reasonable way to start a working day. Gmail first, then Linear for any new issues, then the client’s Slack workspace, then Notion for anything that had been assigned overnight, then back to Gmail because something always arrived while I was doing the other four. By the time I had finished the loop, twenty minutes had passed and I had retained maybe a third of what I had looked at because context-switching at that speed does not actually produce comprehension. It produces the feeling of having checked things.
The missed support message cost the client four hours of downtime escalation. It did not cost me the client, but it cost me the kind of thing that does not show up on an invoice: credibility in a situation where I needed it.
That night I built the workflow. Not immediately, not calmly. I sat down irritated and started pulling nodes onto the canvas and figuring out what I actually needed to see at the start of every day and what I was checking out of habit rather than necessity.
The core of it is a scheduled trigger that fires at seven forty-five every weekday, which gives me a digest before I would normally open any of those tools. From there, the workflow runs parallel branches using the Split In Batches approach, with each branch handling one data source. An HTTP Request node hits the Linear API to pull any issues assigned to me or updated in the last sixteen hours. Another hits the Gmail API via the native n8n node and filters for anything unread from a specific label I use for client communications. A third calls the Slack API to retrieve unread direct messages across the three workspaces I maintain. The Notion branch was the painful one, which I will come back to.
Each branch feeds into a Set node that normalises the data into a consistent structure: source, title, summary, URL, timestamp. This part matters more than people think. When you are aggregating from five different APIs, the response shapes are completely different. Linear gives you an object with an identifier key. Gmail gives you a payload that requires base64 decoding for the body. Slack gives you a message array where the text field is sometimes absent if the message contained only an attachment. If you do not normalise before merging, you end up with a Code node that is doing five different jobs badly instead of one job well.
The Notion branch broke me for an afternoon. The n8n Notion node documentation says you can filter a database by last edited time using a date filter. This is technically true but functionally misleading, because the filter uses the last edited time in UTC and does not account for the fact that Notion’s API returns times in UTC while the filter builder in the n8n UI presents a local time picker with no indication of the conversion. I spent three hours wondering why my filter was returning records from the wrong time window before I found a community thread where someone had hit the same issue and solved it by using an HTTP Request node directly with a manually constructed filter body instead of the native node. The native node is fine for simple things. For anything involving time-based filtering, build the API call yourself.
After normalisation, everything merges into a single array, which then goes into a Code node that sorts by timestamp and groups by source. The output goes to two places simultaneously: a formatted message posted to a private Slack channel I keep for personal ops, and a row written to a Google Sheet that I use as a low-fidelity log. The Slack message is the one I actually read. The Sheet is there for the week in review, mostly.
The whole workflow runs in about twelve seconds. It costs nothing in the sense that the APIs I am hitting are within their free tiers for this usage volume, and the n8n instance is already running on EC2 for other things.
What I did not do was build this in Zapier, and I want to be specific about why. Parallel execution in Zapier is not a feature. Everything in a Zap is sequential. If I wanted to pull from five data sources, I would need to do it in series, which means the last API call happens after the first four have completed, and if any of them is slow or returns an error, the whole thing stalls or fails. n8n runs branches in parallel by design and handles partial failures with error outputs that you can route independently. This is not a minor difference. It is the architectural reason why Zapier is the right tool for connecting two things that should talk to each other and the wrong tool for anything that requires coordinating multiple data sources into a coherent output.
The workflow did not fix the morning. But it fixed the part of the morning that was producing errors, which is the part where I was trying to hold too many contexts simultaneously and failing to hold any of them properly.
Build fewer dashboards. Build one that shows you only what changed and only what requires a decision. Everything else is noise you are mistaking for diligence.
Olaitan Oladipo holds a BSc in Sociology from Olabisi Onabanjo University. He is a self-taught automation builder who has spent years inside n8n doing the work that most tutorials skip: debugging OAuth errors at 2am, migrating client automations from Make.com mid-project, fighting reverse proxy misconfigurations on AWS EC2, and figuring out through trial and error what actually holds up in production versus what only looks clean in a demo.
He is not a developer by training and not a SaaS founder. He is the person in the Discord server who actually answers the question instead of linking to the docs.
His writing on n8n Automation Tutorial covers self-hosting, AI agent workflows, tool comparisons, and the security vulnerabilities the automation industry would rather not discuss. He has built AI-assisted invoice approval flows using OpenAI function calling, connected Claude via HTTP Request nodes, and holds considered opinions about Zapier, Make.com, LangChain, and CrewAI that their marketing teams would not appreciate.
He writes for people who are technical enough to follow a tutorial but experienced enough to want the honest version.