Alerts never being sent

We’ve made a few changes to our server and now the alerts aren’t being consistently sent. Test emails work fine.

In Troubleshooting logs, I see lots of notification triggers have started but they never complete.

Would having transforms running stop alerts being generated?

Other big change we’ve made is to move back from using Docker to Windows running as a service. That shouldn’t make a difference though.

{
  "browser-info": {
    "language": "en-GB-oxendict",
    "platform": "Win32",
    "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/152.0.0.0 Safari/537.36",
    "vendor": "Google Inc."
  },
  "metabase-info": {
    "databases": [
      "postgres"
    ],
    "run-mode": "prod",
    "plan-alias": "",
    "version": {
      "date": "2026-08-19",
      "tag": "v0.63.14",
      "hash": "8429d62"
    },
    "settings": {
      "report-timezone": "Europe/London"
    },
    "hosting-env": "unknown",
    "application-database": "postgres",
    "application-database-details": {
      "database": {
        "name": "PostgreSQL",
        "version": "17.2"
      },
      "jdbc-driver": {
        "name": "PostgreSQL JDBC Driver",
        "version": "42.7.12"
      }
    }
  },
  "system-info": {
    "file.encoding": "UTF-8",
    "java.runtime.name": "OpenJDK Runtime Environment",
    "java.runtime.version": "21.0.3+9-LTS",
    "java.vendor": "Eclipse Adoptium",
    "java.vendor.url": "https://adoptium.net/",
    "java.version": "21.0.3",
    "java.vm.name": "OpenJDK 64-Bit Server VM",
    "java.vm.version": "21.0.3+9-LTS",
    "jvm.available-processors": 6,
    "jvm.max-memory": "7.3 GB",
    "os.name": "Windows Server 2022",
    "os.version": "10.0",
    "system.total-memory": "29.3 GB",
    "user.language": "en",
    "user.timezone": "Europe/London"
  }
}
```

There’s only one Quartz worker, so if its stuck running a long transform job other stuff will back up behind it.

Is there any way to start a 2nd worker?

What if I span up a 2nd jar? Would that take some of the load?

There’s no documented config option to change the number of Quartz workers.

I don’t know if cluster mode buys you one worker per node, that’s a good question.

The problem you might run into is multiple transforms running at once which could cause database load issues and end up blocking the workers anyway.

There’s only one transform every 30 minutes. It’s just updating Materialised Views. I can pre-cache and get the time down to probably 10 minutes. I’ll try the 2nd server to see what happens. Won’t be until later this week though.

That sounds like a reasonable test. If the transform is holding the scheduler for ~10–30 minutes, alerts due during that window can queue up, and if something hangs rather than finishes, they may never get a chance to run.

Before adding the second server, I’d also check whether the materialized view refresh is blocking or waiting on DB locks. If possible, try scheduling the transform away from alert-heavy times, or refresh the materialized views outside Metabase and let Metabase only query the finished result. If you do test a second Metabase instance, make sure it’s using the same application database and keep an eye on duplicate/background jobs and database load.

Sorry, this has become split over multiple threads now as there have been different directions of investigation.

Looks like it’s not the transforms that are the problem. It’s the processing time. Happens with longer running alert queries too. Eventually, it just gives up with a lot of the alerts just showing as ‘starting’.

I’m working my way through the problem queries.