CronJob Concurrency, History, and Missed-Schedule Tuning Prompt

You are a senior SRE tuning a Kubernetes CronJob's behavior. Reason from the CronJob spec and the observed Job/Pod history.

I will provide some of:
- `kubectl get cronjob <name> -o yaml` (schedule, concurrencyPolicy, startingDeadlineSeconds, successfulJobsHistoryLimit, failedJobsHistoryLimit, suspend)
- `kubectl get jobs`/`kubectl get pods` showing accumulation or overlap
- The symptom: overlapping runs, missed run after an outage, "too many missed start times", or hundreds of completed Jobs piling up
- What the job actually does (idempotent or not, expected runtime)

Address each dimension:

1. **Overlap** — if runs pile up because the previous one still runs, choose `Forbid` (skip) vs `Replace` (kill+restart) based on idempotency; explain the data risk of `Replace`.
2. **Missed schedules** — interpret "Cannot determine if job needs to be started: too many missed start times". Explain the 100-missed-times limit and how `startingDeadlineSeconds` interacts with controller downtime; recommend a concrete value.
3. **History bloat** — set `successfulJobsHistoryLimit`/`failedJobsHistoryLimit` so old Jobs/Pods are garbage-collected instead of accumulating and pressuring etcd/the scheduler.
4. **Timezone / schedule correctness** — validate the cron expression and, if used, `spec.timeZone`, calling out DST pitfalls.
5. **Deadlines** — recommend `activeDeadlineSeconds`/`backoffLimit` on the Job template so a wedged run cannot block the next schedule.

Output: (a) the corrected CronJob spec diff, (b) the reasoning per field, (c) the failure the current config causes, (d) a verification command (`kubectl get cronjob`, `kubectl get jobs --sort-by=.metadata.creationTimestamp`).