The history tab is where almost every Make.com debugging session should start, and it is also where most of them stall, because a busy scenario’s history is mostly rows you do not care about. Knowing which columns carry signal, and how to hide the ones that do not, turns it from a wall of timestamps into a diagnostic tool.
Paste your logs into the Free Analyzer to check this: analyze your logs free.
Why is history two logs in one tab?
The first thing that confuses people is that the history is not only a list of runs. The history contains information about both scenario runs and user changes to the scenario, and it is found by clicking a scenario in the list and going to the history tab.
Those user changes are a separate entry type. Change log entries record scheduling changes, edits, and activation. That matters more than it sounds: when a scenario “suddenly” broke, an edit or an activation entry sitting just before the first bad run is often the whole answer, and it is visible without opening anything.
Which columns actually carry signal?
Three of those do most of the work. Status narrows the failure class immediately. Operations completed is the cheapest progress signal there is: a run that normally consumes forty operations and consumed four stopped early, whatever its status says, which points at the first few modules before you open anything. Duration catches the opposite case, a run that took far longer than usual and probably waited on something external.
Size of transferred data is worth a glance when the symptom is an empty or truncated result, since a run that moved almost no data usually received almost none.
Operations counts are only interpretable once you know what one is. An operation is a single module run to process data or check for new data, and a module’s number of operations depends on the number of bundles it processes, so a module sending five emails consumes five operations. The exception is trigger modules, which run once to check for or retrieve data regardless of how many bundles they return. That exception is why a run can show a very low operation count and still have received plenty of data: the trigger counts once no matter what it found.
While a scenario is running, the same numbers are visible on the canvas: the checkmark icon in the bubble above each module shows that module’s operation count, and the coin icon shows the credits those operations consumed.
How do you hide the noise before reading?
A polling scenario’s history is dominated by runs where nothing happened, and they bury the rows you need.
Clicking the three dots in the upper right corner of the history tab lets you enable or disable “hide check runs” and “hide change log”. The first one is the important one: if you disable check runs, the history stops displaying scheduled runs that check for new data but do not return anything. On a scenario polling every fifteen minutes, that single toggle can remove the overwhelming majority of rows.
You can also reduce the width of the problem. Clicking the filter icon on the right-hand side of the history opens a dropdown where you unselect the columns you want to hide, and the tab then displays only the selected columns.
Keep the change log visible while investigating a regression, and hide it when you are scanning for a pattern across runs.
What do you see when you open a run?
The row tells you that something went wrong; the detail view tells you what.
You can view full information about a specific run, including the bundles processed, in the details of the history tab, which lets you inspect module outputs and logs and understand how a scenario behaved, for example if a module returned an unexpected value. To get there, find the run entry in the history tab and click details on the right-hand side of the entry.
Inside, you can check the output bundles of a specific module from that run, see general information about the run, and switch between a simple log and an advanced log. Start on the simple log to find the module that matters, then switch to advanced only for that one. Reading advanced logs top to bottom is how an hour disappears.
This is the step that answers why a scenario finished successfully and still produced the wrong result, because the wrong value is visible in a bundle even when no module reported an error.
Can you replay a run instead of re-triggering the scenario?
The history offers a run replay, and opening a replayed run shows its details in a new tab, so you can see it without leaving your current view.
The practical value is that you can inspect a past run’s behaviour without firing the trigger again, which matters when re-triggering would create duplicate records downstream, or when the original input is no longer reproducible.
When should you export to CSV?
Some questions are not answerable one run at a time: how often has this failed this month, did the failures cluster at a time of day, did operation counts drift before anything broke.
The history can be exported as a CSV file for deeper analysis by clicking the three dots in the upper right corner, selecting export to CSV, and the file downloads to your device including key scenario execution data. Once it is a spreadsheet, patterns across dozens of runs become obvious in a way that scrolling never makes them.
How long you actually have
History is not permanent, and the window is not the same for everyone: the number of days your run history entries are stored depends on your Make.com plan.
This has one practical consequence worth building a habit around: when something breaks, export or screenshot the relevant runs early. An intermittent failure investigated three weeks later can easily have lost the last known-good run it needed to be compared against, and comparing a working run to a failing one is the technique that most often resolves these.
Which three questions does history answer fastest?
In practice most sessions reduce to one of three questions, and each has a specific path through this tab.
Did it run at all? Look for a row at the expected time, with check runs hidden so an empty poll does not masquerade as a real execution. If there is no row, the cause is the trigger, and the debugging order starts from there rather than from any module.
Did it get as far as it should have? Compare operations completed against a normal run. A short count means it stopped early; a normal count with a wrong result means the flow was fine and the values were not.
What changed? Read the change log entries around the first bad run, then open that run’s details and compare its bundles against the last good one. If the run is parked rather than failed outright, it will be in the incomplete executions queue instead.
One caveat applies to all three. Make is a transactional system in which each execution goes through an initialization phase, one or more cycles, and a finalization phase, and during initialization all necessary connections are created and verified and each module is checked for whether it can perform its intended operations. A failure in that phase happens before any module does work, so it will not present as a module-level error in the way you expect, and the run may carry almost no operations at all.
Which question does history answer fastest?
| Question | Where to look | What tells you the answer |
|---|---|---|
| Did it run? | The run list for the time window | Presence or absence of a run |
| Where did it break? | The run detail, module by module | The first module whose status differs |
| What data did it actually receive? | The bundle on a specific module | The input, not just the output |
| Does the pattern span many runs? | A CSV export | Trends the single-run view cannot show |
Limitations
This covers what the history tab exposes, not what your specific modules should have produced, which is scenario-specific. Retention, and therefore how far back any of this reaches, is set by Make and differs between accounts.
The exported CSV contains key execution data rather than full bundle contents, so it supports pattern analysis rather than replacing the detail view. ScenarioTrace’s Free Analyzer reads exported logs and is deterministic-first with AI-assisted reasoning as a fallback, so treat its output as a diagnosis to confirm against the history itself.
This article was drafted with AI assistance and checked against cited sources through ScenarioTrace’s editorial workflow.
Make and Make.com are trademarks of their respective owner. ScenarioTrace is an independent tool and is not affiliated with or endorsed by Make.