# Homey script App cashes often, error "Exit Code: null, Exit Signal: SIGKILL" **URL:** \ **Category:** Apps\ **Tags:** homeyscript\ **Created:** [June 15, 2026, 3:19pm UTC](https://community.homey.app/t/homey-script-app-cashes-often-error-exit-code-null-exit-signal-sigkill/156205 "2026-06-15T15:19:56Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![Amersfoort](https://avatars.discourse-cdn.com/v4/letter/a/94ad74/32.png) [@Amersfoort](https://community.homey.app/u/Amersfoort)\ **Post date:** [June 15, 2026, 3:19pm UTC](https://community.homey.app/t/homey-script-app-cashes-often-error-exit-code-null-exit-signal-sigkill/156205/1 "2026-06-15T15:19:56Z")
I have dozens of scripts in Advanced flows. On an irregular basis, the Homey script app crashes with the error message “Exit Code: null, Exit Signal: SIGKILL”. According to AI: “This happens in 99% of cases because the script consumes too much working memory (RAM) or keeps the processor (CPU) occupied for too long without interruption”. How can I identify the cause of this error and in which script it occurs? ---
**Author:** ![Peter\_Kawa](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/peter_kawa/32/173848_2.png) [@Peter\_Kawa](https://community.homey.app/u/Peter_Kawa)\ **Post date:** [June 15, 2026, 3:35pm UTC](https://community.homey.app/t/homey-script-app-cashes-often-error-exit-code-null-exit-signal-sigkill/156205/2 "2026-06-15T15:35:13Z")
A script can start multiple instances, like, when it started while it wasn’t finished yet, it starts another instance. Running too many instances causes excessive RAM usage. You can check Insights Homeyscript Memory usage, for _when_ it happens, this might point you to the suspect scripts. ![Screenshot_20260615_173458_Vivaldi](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/7/b/7b0f62ee74bfc731b9c75f02d340c7c36d8a5d64.jpeg) (This is just to point to the graph, it’s not an example of destructive RAM peaks) ---
**Author:** ![Amersfoort](https://avatars.discourse-cdn.com/v4/letter/a/94ad74/32.png) [@Amersfoort](https://community.homey.app/u/Amersfoort)\ **Post date:** [June 16, 2026, 7:41am UTC](https://community.homey.app/t/homey-script-app-cashes-often-error-exit-code-null-exit-signal-sigkill/156205/3 "2026-06-16T07:41:11Z")
At 9:30 the Homey script app went down with a 40% CPU usage ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/a/6/a627a3de7591541c533f88c40e88651bfdfdf7cc.png) ---
**Author:** ![robertklep](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/robertklep/32/160628_2.png) [@robertklep](https://community.homey.app/u/robertklep)\ **Post date:** [June 16, 2026, 8:02am UTC](https://community.homey.app/t/homey-script-app-cashes-often-error-exit-code-null-exit-signal-sigkill/156205/4 "2026-06-16T08:02:19Z")
> [@Amersfoort](#): > > At 9:30 the Homey script app went down with a 40% CPU usage The spike in CPU usage is due to the app starting back up again, it looks like it got killed because of a memory leak that caused the amount of RAM being used to slowly increase. ---
**Author:** ![Amersfoort](https://avatars.discourse-cdn.com/v4/letter/a/94ad74/32.png) [@Amersfoort](https://community.homey.app/u/Amersfoort)\ **Post date:** [June 16, 2026, 8:46am UTC](https://community.homey.app/t/homey-script-app-cashes-often-error-exit-code-null-exit-signal-sigkill/156205/5 "2026-06-16T08:46:49Z")
How could I identify which scripts are causing this memory leak? Some scripts are executed sequentially. The number of combinations is too large to test each script individually. It is more likely the combination of scripts to be executed. Or is a memory leak something that Athom needs to investigate? ---
**Author:** ![robertklep](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/robertklep/32/160628_2.png) [@robertklep](https://community.homey.app/u/robertklep)\ **Post date:** [June 16, 2026, 8:50am UTC](https://community.homey.app/t/homey-script-app-cashes-often-error-exit-code-null-exit-signal-sigkill/156205/6 "2026-06-16T08:50:56Z")
> [@Amersfoort](#): > > How could I identify which scripts are causing this memory leak? Some scripts are executed sequentially. Simply said: you can’t 🤷🏼‍♂️ You have to do some guessing which scripts could be candidates for memory leaks. For instance, scripts that use timers (`setTimeout/setInterval`), callback functions (like event handlers, etc) or scripts that use globals a lot. And/or scripts that have been generated by “AI”, since LLM’s don’t understand the intricacies of running HomeyScript. > [@](#): > > The number of combinations is too large to test each script individually. It is more likely the combination of scripts to be executed. Doubtful, at least I don’t see why a _combination_ of scripts could cause a leak where an individual script can’t. > [@](#): > > Or is a memory leak something that Athom needs to investigate? It’s more than likely not an issue with the HomeyScript app itself. ---
**Author:** ![Peter\_Kawa](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/peter_kawa/32/173848_2.png) [@Peter\_Kawa](https://community.homey.app/u/Peter_Kawa)\ **Post date:** [June 16, 2026, 1:50pm UTC](https://community.homey.app/t/homey-script-app-cashes-often-error-exit-code-null-exit-signal-sigkill/156205/7 "2026-06-16T13:50:19Z")
I don’t think it’s a memory leak. Like I already wrote, every running (instance of a) script increases Homeyscript’s RAM use, until it gets past a threshold at some point, and Homey kills it. 150MB RAM usage really is huge, here it’s around 116MB in general. I’d first check scripts which wait for a value or input; these can have many running instances \> which should be avoided as much as possible. And I’d check on scripts which get executed very often (less than each minute or so). ---
**Author:** ![Amersfoort](https://avatars.discourse-cdn.com/v4/letter/a/94ad74/32.png) [@Amersfoort](https://community.homey.app/u/Amersfoort)\ **Post date:** [June 17, 2026, 9:01am UTC](https://community.homey.app/t/homey-script-app-cashes-often-error-exit-code-null-exit-signal-sigkill/156205/8 "2026-06-17T09:01:18Z")
I generate ~20 full screen SVGs and Markdown tables (not at the same time) using multiple Homey scripts by selecting dashboard menu options. The results are sent to that dashboard via a subsequent card using a script Return variable. It seems that the memory of these variables is not being cleared, or is being cleared poorly, even after Advanced Flow has finished. I reboot the Homey device every night. Any tips? ---
**Author:** ![robertklep](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/robertklep/32/160628_2.png) [@robertklep](https://community.homey.app/u/robertklep)\ **Post date:** [June 17, 2026, 9:30am UTC](https://community.homey.app/t/homey-script-app-cashes-often-error-exit-code-null-exit-signal-sigkill/156205/9 "2026-06-17T09:30:45Z")
This sort of usage is probably something that Athom never considered, so it wouldn’t surprise me if indeed there’s data left dangling. However, it’s nearly impossible to debug where, and if it’s even possible to fix it. So other than rebooting Homey nightly, or the HomeyScript app, you will keep running into this issue. ---
**Author:** ![Amersfoort](https://avatars.discourse-cdn.com/v4/letter/a/94ad74/32.png) [@Amersfoort](https://community.homey.app/u/Amersfoort)\ **Post date:** [June 17, 2026, 9:46am UTC](https://community.homey.app/t/homey-script-app-cashes-often-error-exit-code-null-exit-signal-sigkill/156205/10 "2026-06-17T09:46:34Z")
Yes, but the Homey script app restarts multiple times a day with this error message, causing the Homey scripts to stop responding. ---
**Author:** ![robertklep](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/robertklep/32/160628_2.png) [@robertklep](https://community.homey.app/u/robertklep)\ **Post date:** [June 17, 2026, 9:50am UTC](https://community.homey.app/t/homey-script-app-cashes-often-error-exit-code-null-exit-signal-sigkill/156205/11 "2026-06-17T09:50:40Z")
You can restart it from a flow: ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/8/5/851068b30585493265a98f250076934b90c52744.png) (possibly only when the Power User experiment is turned on) Otherwise I don’t see any other solution. ---
**Author:** ![WimWeetjens](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/wimweetjens/32/79635_2.png) [@WimWeetjens](https://community.homey.app/u/WimWeetjens)\ **Post date:** [September 16, 2026, 1:57pm UTC](https://community.homey.app/t/homey-script-app-cashes-often-error-exit-code-null-exit-signal-sigkill/156205/12 "2026-09-16T13:57:53Z")
Adding measurements to this thread, because I see exactly the same pattern on a Homey Pro (2023), HomeyScript 3.6.3, and it looks like a **per-execution leak** rather than “too many parallel instances”: **Setup:** ~30 scripts, mostly small (5–50 kB, no timers/intervals/event handlers, each run finishes in a few seconds), started from flows: cron ticks every 5/15 min plus device-triggered flows. Persistent globals total 243 kB. **Observation:** the app’s memory (`usage.mem` via the Web API) grows linearly with the _number of script executions_, largely independent of script size: - ~55 executions/hour → +18 MB/h - ~85 executions/hour → +35 MB/h → roughly **0.35–0.4 MB retained per execution**. From a fresh ~90 MB baseline the app hits the memory limit (“Memory Warning Limit Reached” → crash) after 3–6 hours; 14 crashes in the last two days. A controlled restart (`POST /api/manager/apps/app/com.athom.homeyscript/restart`) brings it back to ~90 MB every time. GC does free some of it between runs (we’ve seen 143 → 115 MB with no restart), but the trend keeps climbing. **What helps:** reducing the number of executions helps proportionally — we gated device-triggered flows with conditions so the script only starts when it can actually decide something, disabled redundant event flows, and restart the app nightly + when it passes 150 MB. That keeps it alive, but it’s a workaround. @Athom: is the per-execution sandbox/VM known not to be fully released? Happy to share the memory time series and the script list if useful. ---
**Author:** ![Amersfoort](https://avatars.discourse-cdn.com/v4/letter/a/94ad74/32.png) [@Amersfoort](https://community.homey.app/u/Amersfoort)\ **Post date:** [September 16, 2026, 2:21pm UTC](https://community.homey.app/t/homey-script-app-cashes-often-error-exit-code-null-exit-signal-sigkill/156205/13 "2026-09-16T14:21:56Z")
I think the GC is not doing a great job. I manually clear the variables with somewhat larger content, containing an array or json. ---
**Author:** ![robertklep](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/robertklep/32/160628_2.png) [@robertklep](https://community.homey.app/u/robertklep)\ **Post date:** [September 16, 2026, 2:49pm UTC](https://community.homey.app/t/homey-script-app-cashes-often-error-exit-code-null-exit-signal-sigkill/156205/14 "2026-09-16T14:49:15Z")
> [@Amersfoort](#): > > I think the GC is not doing a great job Or everyone is using AI to create leaky scripts and have no idea where to look for memory leaks in their own scripts. ---
**Author:** ![WimWeetjens](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/wimweetjens/32/79635_2.png) [@WimWeetjens](https://community.homey.app/u/WimWeetjens)\ **Post date:** [September 16, 2026, 3:05pm UTC](https://community.homey.app/t/homey-script-app-cashes-often-error-exit-code-null-exit-signal-sigkill/156205/15 "2026-09-16T15:05:19Z")
Fair challenge, so I measured instead of assuming — and I have to correct my own post above. **Test (HomeyScript 3.6.3, Homey Pro 2023):** ran a scratch script in batches of 6–22 executions, reading the app’s `usage.mem` every 10 s for ~2 minutes after each batch and taking the post-GC floor: | batch | runs | floor before → after | | --- | --- | --- | | `return 1` | 22 | 105.4 → 105.6 MB | | `getDevice()` ×11 per run | 6 | 105.6 → 105.6 | | `getDevices()` (127 devices) | 8 | 105.6 → 120.6 → back to 105.6 within ~2 min | | `getVariables()` | 8 | 105.6 → 105.6 | | `fetch()` external JSON | 8 | 105.7 → 105.7 | ~70 executions in 15 minutes (plus the normal cron scripts running in between): **the floor did not move**. So no per-execution leak, at least not for these primitives — my earlier “0.35–0.4 MB per run” was an artefact of sampling while executions were in flight. What the readings _do_ show: every execution is a transient +15 to +50 MB (the `getDevices()` batch peaked at 154 MB from a 105 MB floor), released after the run. Our crashes line up with moments where several scripts run concurrently (a 06:00 cluster of daily jobs, morning device events + cron ticks, my own test runs on top of the 5-minute ticks) — i.e. exactly @Peter_Kawa’s explanation: it’s the _sum of simultaneous VMs_ hitting the limit, not a slow leak. Practical consequences for anyone with the same symptom: stagger cron-driven scripts so they don’t fire in the same second (delays of 60–240 s work), gate device-triggered scripts with flow conditions so they only start when they can decide something, avoid `getDevices()` in frequently running scripts (fetch the few devices you need by id — a much smaller VM), and keep scripts short-running (no long `wait()` loops that overlap with the next tick). Nightly restart as belt-and-braces. Apologies for the noise, @robertklep — the measurement was worth doing.