COB recovery
T24 COB After a Database Restore
A database restore changes the authoritative recovery point. Do not assume that application, messaging, file, scheduler, and downstream state automatically moved to the same point in time.
Browse more COB articles →
Separate restored database state from later external work
The restored database contains state as of the chosen backup or recovery point. It cannot contain transactions created after that point. However, queues, integration services, files, application memory, schedulers, and downstream systems may still hold or reflect work created after the database recovery point.
That later external work must be isolated and reconciled. A message can refer to a transaction that is absent from the restored database, while a downstream system may already have accepted work that the restored database no longer records as complete.
1. Declare the recovery point
- Database restore timestamp and recovery method
- Business date represented by the restored data
- Application, messaging, and file-system components included or excluded
- Known processing completed after the recovery point
- Recovery owner and approved restart boundary
2. Keep interfaces isolated
Prevent inbound and outbound work from changing the state while the recovery position is being assessed. Confirm producer, consumer, file-transfer, API, OFS, and gateway isolation through the controls documented for the environment.
3. Map COB and service state
- Current T24 business date and expected COB stage
- Scheduler and service records represented in the restored database
- Runtime process and agent state on each application host
- Outstanding, completed, failed, and partially processed jobs
- Any control state manually changed before or after the restore
A control screen, runtime process, and database record can describe different moments. Capture all three before changing a status or restarting a service.
4. Reconcile later work
Build a timeline from the recovery point to the outage. For each message, file, batch job, or payment that may have progressed later, determine whether it committed in T24, was acknowledged externally, or remained uncertain. Preserve original identifiers and link any authorised retry to the original attempt.
5. Validate before COB resumes
- Validate database consistency and business date.
- Validate application services without opening external traffic.
- Run an approved controlled transaction or read-only verification path.
- Confirm messaging, file, and downstream state against the reconciliation plan.
- Confirm the intended COB restart stage and outstanding job list.
- Obtain technical and business approval before normal processing resumes.
6. Verify the resumed cycle
A green COB status is not sufficient. Check expected jobs, reports, files, balances, interfaces, acknowledgements, and business-date controls. The guide to why batch success can be misleading provides the closeout checks.
Escalation evidence
- Recovery point and component-state map
- COB stage, business date, service and scheduler state
- Outstanding queues, files, messages, and jobs
- Known later acknowledgements or downstream completions
- Duplicate-risk decisions and authorised containment actions
- First failed validation and required decision
Package the evidence using the incident escalation checklist.
Related reading
What Is COB in T24? Close of Business Explained
A plain-English introduction to Close of Business (COB) in Temenos T24 — what it does, why it matters, what the batch actually processes, and what to do when it does not complete.
COB and supportWhy Batch Success Can Be Misleading in T24
A practical T24 operations guide to proving that a completed batch produced the expected business outcome, not only a successful return status.
Production supportFive Things to Check Before Escalating a T24 Incident
The difference between a junior analyst and an experienced one is often ten minutes and a short checklist. Five questions to answer before you pick up the phone.