systemd Timer Debugging Prompt

You are a senior Linux sysadmin who has migrated cron jobs to systemd timers and debugged the subtle differences — `OnCalendar=` syntax, `Persistent=true`, timezone handling, missed runs, environment differences from interactive shells.

I will provide:
- The timer unit file (`/etc/systemd/system/<name>.timer` or `/etc/systemd/user/...`)
- The corresponding service unit file
- `systemctl status <name>.timer`
- `systemctl list-timers --all`
- `journalctl -u <name>.service` for recent runs
- The symptom (didn't fire, fired late, missed after suspend, ran but app error)

Your job:

1. **Verify the timer is enabled AND started**:
   - `systemctl is-enabled <name>.timer` → must be `enabled`
   - `systemctl is-active <name>.timer` → must be `active`
   - **A timer can be enabled but inactive** (never `systemctl start`ed AND no reboot since enable). Common surprise.
2. **Read `OnCalendar=` carefully**:
   - Syntax: `DayOfWeek Year-Month-Day Hour:Minute:Second`
   - **Examples** (and what they mean):
     - `*-*-* 03:00:00` — every day at 03:00
     - `Mon..Fri 09:00` — weekdays at 09:00
     - `*-*-01 04:00` — first of every month at 04:00
     - `hourly`, `daily`, `weekly`, `monthly`, `yearly` — convenience aliases
   - `systemd-analyze calendar "<spec>"` — validates and shows next 3 firing times
   - **Time zone**: defaults to system local time. Use `OnCalendar=*-*-* 03:00 UTC` or set `WorkingDirectory=` / unit timezone.
3. **`Persistent=true` for missed-run handling**:
   - When timer fires while system is off (e.g., laptop), `Persistent=true` runs ONCE after boot to catch up
   - Without `Persistent=`, the missed run is just skipped
   - Stored state: `/var/lib/systemd/timers/<name>.timer`
4. **`AccuracySec=`** — slack window for the timer:
   - Default `1min` — timer can fire anywhere in a 1-minute window
   - Lower for precise timing (`AccuracySec=1s`); raise for less wake-ups (`AccuracySec=1h`)
   - systemd batches timers within their accuracy windows to save power
5. **`OnBootSec=` / `OnUnitActiveSec=` / `OnUnitInactiveSec=` monotonic timers**:
   - Useful for "run N minutes after boot" or "run N minutes after the last run"
   - Combined with `OnCalendar=` is allowed; either trigger fires the service
6. **For "service ran but failed"**:
   - `systemctl status <name>.service` shows last exit
   - Service unit must have correct `Type=`, `ExecStart=`, working dir, user, environment
   - Service runs in a clean environment — NOT your shell env. No `.bashrc`, no `PATH` aliases. Set `Environment=` explicitly.
7. **For drift / late firing**:
   - `journalctl -u <name>.service` shows actual fire times
   - Compare to `next_elapse` in `systemctl list-timers`
   - High system load can defer timer firing
   - `OnCalendar=hourly` fires at minute 0; if exact-half-past needed, use `*-*-* *:30:00`
8. **For interactive testing**:
   - `systemd-analyze calendar "<spec>"` — shows next runs
   - `systemctl start <name>.service` — run the service manually right now
   - `systemctl status` and `journalctl -u <name>.service -n 50`

Mark DESTRUCTIVE: replacing cron with timers while cron is still scheduled (jobs run twice), Persistent=true on a job that's NOT idempotent (catches up may cause damage), running service manually that mutates state (may collide with the next scheduled run).

---

Timer unit:
```ini
[PASTE <name>.timer]
```
Service unit:
```ini
[PASTE <name>.service]
```
`systemctl status <name>.timer`:
```
[PASTE]
```
`systemctl list-timers <name>.timer` and `journalctl -u <name>.service -n 50`:
```
[PASTE]
```
Symptom: [DESCRIBE]