If I change permissions to 444, log in to my site, then change the permissions back to 400.
In other words: with permissions 400, your scripts cannot read the file, but with permissions 444, they can, and then some process will be either keeping the file open or keeping the credentials in RAM until midnight, when something triggers a restart or clean-up of some sort.
You did not mention the OS/distribution you're using, but I would start by checking
/etc/cron.* and the crontabs of any relevant users (usually in
/var/spool/cron[/crontabs] or similar) for any daily cron jobs running at midnight. Perhaps there's something that cleans up old PHP sessions? Or perhaps it's
logrotate triggering a restart of something like
php-fpm as part of a daily log rotation schedule?
If your system uses
systemd, also check its timer units:
systemctl list-units --type=timer to list all system-wide timers, and then
systemctl cat <name>.timer to view them.
For example, in Debian 12,
logrotate could be triggered by
/etc/cron.daily/logrotate, which might run by
anacron at the time specified in
/etc/cron.d/anacron, by default the earliest time between 07:30 and 23:30 when the system is running... but this schedule will actually be used only if
systemd is not in use, as the job specified in
/etc/cron.d/anacron is conditional to
/run/systemd/system not existing.
logrotate.timer is used instead, and it is specified like this:
systemctl cat logrotate.timer
Description=Daily rotation of log files
As described in
*-*-* 00:00:00, i.e. every day exactly at midnight. The
AccuracySec=1h allows coalescing this timer with other timers that trigger between 00:00 and 01:00, if any exist, to optimize power saving. On my system at least, the end result seems to be that the log rotation happens exactly at midnight, unless the system was down at that time.
systemctl status logrotate.timer, you can see the next scheduled trigger time for the timer.