My code node keeps timing out. But it used to work just fine. I dont think its very complex code.
here is the code:
const rawDate = $input.item.json.Date;
const rawTime = $input.item.json.Current_Time;
const parts = rawDate.split(‘-’);
const day = parts[0].padStart(2, ‘0’);
const monthMap = { Jan:‘01’, Feb:‘02’, Mar:‘03’, Apr:‘04’, May:‘05’, Jun:‘06’, Jul:‘07’, Aug:‘08’, Sep:‘09’, Oct:‘10’, Nov:‘11’, Dec:‘12’ };
const mm = monthMap[parts[1]];
const yyyy = 20${parts[2]};
const timeWithMs = rawTime.split(‘T’)[1];
const timePart = timeWithMs.split(‘.’)[0];
const offsetPart = timeWithMs.includes(‘+’) ? +${timeWithMs.split('+')[1]} : -${timeWithMs.split('-')[1]};
return {
…$input.item.json,
Formatted_Date: ${yyyy}-${mm}-${day}T${timePart}${offsetPart}
};
1 Like
const { Date: d, Current_Time: t } = $input.item.json;
const [day, mon, yr] = d.split(‘-’);
const month = {
Jan:‘01’, Feb:‘02’, Mar:‘03’, Apr:‘04’,
May:‘05’, Jun:‘06’, Jul:‘07’, Aug:‘08’,
Sep:‘09’, Oct:‘10’, Nov:‘11’, Dec:‘12’
}[mon];
const time = t.split(‘T’)[1];
const [hms, offset] = time.split(‘.’);
return [
{
json: {
…$input.item.json,
Formatted_Date: 20${yr}-${month}-${day.padStart(2,'0')}T${hms}.${offset || ''}
}
}
];
Welcome @Elan_Savan!
That code is too simple to hit the 60-second limit on its own - date string parsing like this runs in under 1ms. The most likely cause is the item count flowing into the node: Code nodes run once per item by default, so if your upstream data has grown (say 200+ rows from a spreadsheet), the total execution time stacks up and can trip the timeout. Click on the node in the editor and check how many items are at its input.
If the item count looks normal, it may also be a temporary Cloud task runner capacity issue - try toggling the workflow off and on, then re-run in test mode to see if it reproduces consistently.
1 Like
Thanks for the insight, @nguyenthieutoan.
You’re right that the code itself is lightweight and shouldn’t normally hit the 60-second execution limit. The first thing I would check is the number of items entering the Code node, since n8n executes the code for every incoming item by default. If the upstream source is returning hundreds of records, the cumulative execution time could become significant.
I’d also recommend checking:
• Whether the workflow is running in “Run Once for Each Item” or “Run Once for All Items” mode.
• The execution logs to identify which node is actually consuming most of the runtime.
• Any upstream nodes such as HTTP Requests, database queries, or spreadsheet operations that may be introducing delays before the Code node executes.
• Memory usage and workflow execution history if running on n8n Cloud, as temporary task runner congestion can occasionally affect execution times.
For optimization, the date transformation can also be simplified using JavaScript’s native Date handling functions, reducing the amount of string parsing required.
