Log level for UI display and for inbuilt jobs

I have a variety of jobs that might be dosing small amounts as often as every 30 seconds. Even if I set their output (e.g. “pH below setpoint, dosing x mL base”) to debug level, so it’s stored but not not in the UI, the dosing event itself ends up spamming my UI. I’d like to be able to control properly what I see in the UI, my preferred pattern would probably be that jobs print certain stuff to “info” - in my mind a dosing automation job dosing isn’t cause for “info” - it’s supposed to be doing that so it’s more a debug-level thing. But I understand that if people have a job that doses every couple of hours they probably want to see each event. Not sure what the general solution is in this case? I don’t want to have to maintain a fork to change the debug level of the base addition class.

In my mind:

  • Debug: Job is doing what you set it to do, can check this if you want to know
  • Info: Jobs starting/finishing, changing parameters, updates from jobs that a human might want to know, human additions to datastream e.g. “I added 10 mL of x manually here”
  • Notice: Not additions but summaries etc. I plan to use for agentic summaries of status so e.g. claude hits the logs every hour and makes a little summary

Hm, I don’t know an obvious solution here, as you nail it right on the head. We can probably “demote” some of the logs a bit more though.

Could the base automation event be debug and the dosing automation “event” in the default jobs be info? Then if you’re using a custom background job that doses you can choose to display all the events at the info level if you want?