Replace the morning tab ritual
Most mornings start with four tabs: the shop admin, the helpdesk, the uptime monitor, and a spreadsheet somebody maintains. A digest replaces that with one message at a fixed time. The version I build spends most of its effort on what happens when a source stops answering, because that is where every digest I have looked at quietly goes wrong.
The questionHow do I get one daily summary of my sales, support and uptime instead of checking four dashboards?
How the working version is put together
Fire once, early enough to be read
One cron expression fires the whole thing, in this build at half seven. I set it early on purpose: a digest arriving at eleven is competing with the working day and gets skimmed. Sitting in the channel before anyone opens a laptop is the only slot where people reliably read the thing.
Pull the sources in parallel, not in a chain
Three HTTP request nodes hang off the trigger as separate branches. This matters more than it looks, and I have watched people get it wrong: chained, a source returning forty items makes the next node execute forty times, and you end up assembling a digest out of sixteen hundred rows. Each node has alwaysOutputData on and continues on error, so one dead endpoint cannot take the run down with it.
Merge as a waiting room, nothing more
A merge node in append mode with three inputs sits between the pulls and the digest, and its only job is to wait until all three branches have finished. Nothing is joined and nothing is matched. I resist combining the data here because the next step needs to know which source each item arrived from.
Read each source by name, so silence has an address
The code node ignores the merged output and reaches back to each source node by name, counts the usable rows, and pulls up to five headlines from whichever of title, name, summary or id exists. Once items are appended they all look alike, and a digest that cannot tell you which source went quiet is exactly the problem I am trying to avoid.
Say UNAVAILABLE instead of showing a zero
If a source returns nothing usable, it is written into the message as UNAVAILABLE and counted in a warning line at the top. Most digests show a zero when a source fails, and a zero looks identical to a quiet day. I would rather the message admit it is incomplete than let you make a decision on three sources while believing you had four.
Post one plain message to one channel
The last node sends the digest to a Slack channel as plain text. Swapping Slack for email, Telegram or Teams changes that node and nothing else, which I say out loud because somebody will otherwise build a case for migrating chat tools off the back of a digest.
Build a daily ops digest from three HTTP sources and post it to Slack
I have published this as a free n8n template, so you can read every node before you decide whether you want help with it. It is in review on the n8n template library.
What the morning ritual costs
Ten minutes, but they are the wrong ten minutes. Opening four dashboards before deciding what the day is for is how a morning gets spent reacting, and I have lost enough of them to know the tabs are not really the expensive part.
The bigger cost is that nobody else sees it. When the morning check lives in one founder's browser history, the rest of the team has no shared picture of yesterday, and every conversation opens with somebody catching somebody else up. Putting it in a channel turns it into a fact everyone already has, instead of a briefing I have to give.
Where digests go wrong
Sources fail quietly, which is the whole design problem and the reason I build this the way I do. An expired token returns a 200 with an empty list. A rate limit returns 429. A renamed field returns the right number of rows with nothing in them. None of that looks like an error to a workflow, and all of it turns into a digest that reads like a slow Tuesday.
Scope is the other one. A digest built to cover everything gets skimmed for a fortnight and then ignored, and an ignored digest is worse than none because everyone assumes somebody read it. Three sources and five lines each is roughly the ceiling I would build to, and I would rather have the argument about what to leave out before writing any of it.
What it costs to run
Effectively nothing. One run a day, three GET requests, one Slack message. I put no model call in this build and there is no per-item cost anywhere, so on a self-hosted n8n it does not register against the server you already pay for.
The maintenance cost is real though, and it sits in the endpoints rather than the workflow. APIs get versioned, tokens expire, fields get renamed. I would add an assertion per source checking a field you genuinely expect rather than a row count, plus an alert if the same source reports UNAVAILABLE two days running, because otherwise you have built a dashboard nobody opens with extra steps.
Why take this from me
Nine projects needed a morning check long before anyone offered to pay me to build one, so I built it for myself. The dashboard in the work below is the larger version of the same idea: every schedule, agent, task and alert across the estate reporting into one screen, with failures surfaced rather than buried in a log. The build on this page is the small version of it, pulling three sources instead of an estate and posting the result into a channel rather than onto a screen somebody has to remember to open.
It is worth saying plainly that all of this is my own operation. There is no client roster to point at, no testimonials and no case-study numbers, so what I can offer you instead is the running systems and the source code, both of which you can go and read before spending anything with me.
When I would tell you not to build it
If you have one system to check, do not. A digest summarising a single source is a worse version of that source, and I would have added a failure point between you and information you could already see in one click.
Skip it if you already run real observability. A digest like this one arrives once, at a fixed time, and stays quiet for the other twenty three hours, so nothing in it will wake anybody at three in the morning. Grafana, Better Stack or whatever is behind your on-call rota are answering a different question, and I would not want this sitting next to them pretending to be monitoring.
Wait until somebody has agreed what belongs in the digest, and if nobody will own that, leave it unbuilt. That sounds like a formality, and it is the reason most digests die: nobody owns the content, so it grows to twenty lines, and at twenty lines it stops being read. I would rather spend the first hour arguing about what to cut than ship the long version and watch the channel get muted.
What lands on your desk
- The digest running on your schedule, against your endpoints, posting into your channel
- Parallel source pulls, so one slow or dead endpoint cannot stall the run or multiply it
- A message that names any source which did not report, rather than quietly showing you a zero
- Per-source assertions that check a field you expect, not just a row count
- One place in the code where the digest defines itself, so a fourth source is a two-line change
- A written walkthrough, so whoever touches it next is not dependent on me
Open the proof
Published case studies of systems that are running. Each links to the thing itself.
The dashboard this digest is the small version of ↗Booboo on GitHub (MIT, read the code) ↗My Etsy shop, the kits as instant downloads ↗
Questions this page answers
- What happens when a source stops responding?
- It gets written into the message as UNAVAILABLE and counted in a warning line at the top, rather than showing a zero that looks identical to a quiet day.
- Why pull the sources in parallel instead of chained?
- Chained, a source returning forty items makes the next node execute forty times. Parallel branches with continue-on-error mean one dead endpoint can't take the whole run down.
- How much does the digest cost to keep running?
- It costs effectively nothing to run: one call a day makes three GET requests and posts a single Slack message, and I don't put a model call anywhere in the build.
- When should I not build one?
- Skip it if you only have one system to check, or if you already run real observability like Grafana or Better Stack. A once-a-day digest is the wrong tool sitting next to the right one.
Want this built and handed over working?
One line is enough to start. You get an honest answer on fit, and a number rather than a discovery call.
Start a brief