It happened multiple times already with various 0.16.x versions. Each time, the behavior is stalwart has stopped (systemd service is marked as exited) and hasn’t restarted by itself. The logs are unusable. The log page on the web ui saturate at 5000 entries (it starts with 02/26/2026 ASCENDING with only 25 items shown). I’ve clicked 199x times to see the “last” page, but it was in 2026/05/12, for far from today). It doesn’t even contain the latest logs. There’s no way to filter logs by time or date either so it’s useless.
I have set a tracer to log to files, but unfortunately, it doesn’t show anything interesting (since I’ve only selected few categories here, not all of them).
So in the end, I’m completely blind as to why Stalwart is stopping unexpectedly. Notice: no system update happened when it stopped and restarting it manually with systemctl restart works fine.
Expected Behavior
Stalwart shouldn’t stop by itself.
It should log why it failed.
It should have a log page that’s useful (no English time MM/DD on the first column) and sorted DESCENDING by default (or a way to skip to last page)
It shouldn’t saturate logs at 5000 entries, but remove the oldest one if it’s memory limited.
Actual Behavior
Stalwart stopped unexpectedly today and if I wasn’t monitoring it, I wouldn’t have noticed and probably lost emails.
Reproduction Steps
Since I don’t know why it failed, I can’t tell how to reproduce. Just let Stalwart run for month and it’ll stop sometimes. As for the log, just open the log page and try to see the latest logs if you have more than 5000 entries: you can’t.
Relevant Log Output
None and that’s the issue.
Stalwart Version
v0.16.x
Installation Method
Binary (Linux)
Database Backend
PostgreSQL
Blob Storage
Filesystem
Search Engine
Internal
Directory Backend
Internal
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
This looks like a bug report rather than a docs question, so a human will need to look at the actual crash. A few things grounded in the docs that may help in the meantime:
Finding why it stopped: Stalwart’s own tracers (Log/Stdout/Journal) only capture events the process logs before exiting; if it’s killed (e.g., OOM-killed or a segfault) there may be nothing in Stalwart’s own log stream. Check journalctl -u stalwart (or your unit name) around the stop time for OOM-killer or systemd exit-code messages, since that’s tracked independently of Stalwart’s own log objects. If you’re using the Journal tracer, make sure it’s enable: true with level set to at least info so systemd captures the same events. See the Tracer reference for tracer config.
Increasing what’s captured: Tracing/log history retention and storage backend are controlled by the TracingStore singleton and holdTracesFor under Data Retention, not a fixed count. If the WebUI log page is capping at 5000 entries and paginating in ascending order with no date filter, that’s a WebUI display limitation rather than a retention setting, so it wouldn’t be fixable purely via config. See Telemetry History for how retention and the history store work.
I don’t have a documented explanation for the WebUI log page’s sort order, missing date filter, or the unexpected process exit, those are implementation-level issues. A staff or community member should follow up on the reproduction details, especially the systemd exit status and any OOM/segfault entries in the system journal.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
Jul 26 21:34:24 user systemd[1]: Started stalwart.service - Stalwart Mail Server Server.
Sep 29 06:23:09 user systemd[1]: Stopping stalwart.service - Stalwart Mail Server Server...
Sep 29 06:23:10 user systemd[1]: stalwart.service: Deactivated successfully.
Sep 29 06:23:10 user systemd[1]: Stopped stalwart.service - Stalwart Mail Server Server.
Sep 29 06:23:10 user systemd[1]: stalwart.service: Consumed 1h 6min 39.497s CPU time, 618.8M memory peak.
So almost useless.
As for the telemetry, I don’t see any limit in that settings pane. How can I get more logs if it’s not available in the WebUI?
U can configure a logfile and perhaps u should, cause if the ui doesnt work for some reason u need to access the logs otherwise. Then u can work on it with standard unix tools.
A console logger is enabled by default, so its interesting there is nothing in the journal. Perhaps a missconfiguration of the systemd servicefile? I use stalwart with podman and the podman logs is doing fine without any configuration.
I had also incidents where my Stalwart system was stopped.
(2026-09-29T04:21:54Z INFO Shutting down Stalwart Server (server.shutdown) causedBy = “SIGINT”)
Turns out that my VPS was doing automatic updates and in this process it did start exim4
Now automatic updates are switched off and exim4 is removed from my VPS.
What i’m concerned about is the memory peak of 22.8G that’s huge for this small mailserver
Those journal lines are systemd stopping the service because something asked it to; a crash would show an exit code or a signal. The unit that install.sh creates has Conflicts=postfix.service sendmail.service exim4.service, so anything that starts one of those stops Stalwart, and since it exits cleanly Restart=on-failure never brings it back. @Corne’s stop a couple of minutes earlier on the same morning was exactly that, through the daily apt run. Check what else happened around 06:23 and whether a mail transport package came in:
If one turns up, remove it, or mask it with systemctl mask exim4.service.
On the log page, the Text filter matches against each entry’s header line, timestamp included, so typing 2026-09-29T06:2 gets you to that window. The 5000 is the query cap being shown as a total, not how many entries exist, and the page shouldn’t present it that way. For catching a stop like this, a file tracer at info level with no category filter is what I’d keep running.
@Corne, the memory peak systemd reports covers the whole cgroup, page cache included, so it says little about what Stalwart itself used.
I’m not sure if you wanted my logs, special since my logs were already in my post. This 2026-09-29T04:21:54Z INFO Shutting down Stalwart Server (server.shutdown) causedBy = “SIGINT” is the last in my logs till I did restart 4,5 hours later.
Sep 29 06:23:07 user systemd[1]: exim4-base.timer: Deactivated successfully.
Sep 29 06:23:07 user systemd[1]: Stopped exim4-base.timer - Daily exim4-base housekeeping.
Sep 29 06:23:07 user systemd[1]: Stopping exim4-base.timer - Daily exim4-base housekeeping...
Sep 29 06:23:07 user systemd[1]: Started exim4-base.timer - Daily exim4-base housekeeping.
Sep 29 06:23:09 user systemd[1]: Starting exim4.service - exim Mail Transport Agent...
Sep 29 06:23:09 user systemd[1]: Stopping stalwart.service - Stalwart Mail Server Server...
Sep 29 06:23:09 user systemd[1]: man-db.service: Deactivated successfully.
Sep 29 06:23:09 user systemd[1]: Finished man-db.service - Daily man-db regeneration.
Sep 29 06:23:09 user systemd[1]: Started exim4.service - exim Mail Transport Agent.
Sep 29 06:23:10 user systemd[1]: stalwart.service: Deactivated successfully.
Sep 29 06:23:10 user systemd[1]: Stopped stalwart.service - Stalwart Mail Server Server.
Sep 29 06:23:10 user systemd[1]: stalwart.service: Consumed 1h 6min 39.497s CPU time, 618.8M memory peak.
Indeed, certbot somehow triggered starting of exim4 at the same time, and that stopped stalwart. That pesky debian exim that can’t be completely removed without breaking all packages…
I had already masked exim4 service, but it’s the exim4.timer that triggered it. It should be masked as well.
I’ve also added a INFO tracer back without any filter since I had none. Last time, I had removed it because it filled up my drive with logs for every mail transiting in the system (including spam).
Thank you for the pointer, I’d completely forgotten about exim fighting with stalwart.