The end-of-day batch that died at 23:52

What actually happens

Ask any core banking operations lead about their worst recurring night and you will hear a version of this one.

The end-of-day batch starts at 23:30. It is the job that closes the books: settlement, interest accrual, customer statements, the regulatory extract. Everything downstream waits on it. At 23:52 one step exits with a non-zero code and the job stops.

No alert fires. Not because monitoring is broken, but because the scheduler reported the job as finished. It did finish, it just finished badly. The dashboard is green. The exit code is a number in a log nobody is reading at midnight.

Six downstream jobs queue behind it and quietly stall. The reconciliation window closes at 04:00 and passes unremarked. At 06:40 a branch manager calls the service desk because statements are missing, and that call is the detection mechanism.

What follows is a scramble. Someone wakes the batch owner. The batch owner needs the scheduler logs, which need a different access request. By the time anyone understands that a newly onboarded currency pair arrived with a null FX rate and the settlement step divided by it, it is well into the morning. The fix, which is to apply a fallback rate and restart from the failed step, takes a few minutes. The regulatory extract is now late, and someone has to write that up.

And here is the part that stings: the same signature appeared at the previous two month-ends. Nobody connected them, because each one was handled by whoever happened to be on call.

The failure took minutes. Finding it took most of the night. That gap is the entire problem, and it is not a technology gap. It is a nobody-was-looking gap.

The same night, two ways

This is where the MTTR argument actually lives. Not in a percentage. In the clock.

Look at where that night went. Only a few minutes were spent actually fixing the problem. Everything else was detection lag and coordination: nobody watching, then nobody available, then nobody with the full picture.

This is the shape of almost every serious incident. The repair is rarely the expensive part. The expensive parts are the silence before anyone notices, and the hunt to rebuild context the systems already had.

Sentinel does not fix faster. It removes the waiting. Investigation begins at the moment of failure instead of after a human is located, and it arrives with evidence already assembled instead of a starting point.

That is a claim you can check without us. Pull your last ten severity-one incidents and split each clock into detect, route, investigate, fix and verify. If the fix is a small fraction of the total, and in most estates it is, then you already know where your MTTR actually goes.

Who decides to press go

Restarting a core banking batch is not a low-risk action, so Sentinel does not take it alone. The path is chosen by the impact of the remediation, not by how confident the model is in its diagnosis.

The Action Ticket executes under policy. Pre-check, execute, post-check, verify, with automatic rollback if the post-check fails. Nobody is paged.

The ticket is raised and held. The batch owner and change stakeholders are notified with the proposed MOP, blast radius and rollback path attached. Nothing runs until a named human approves.

In the timeline above, the gap between the ticket being raised and the fix running is a human deciding. That is the design, not a delay to be engineered away.

Batch step exits non-zero at 23:52. No operator notification fired. Six downstream jobs queue and stall. Reconciliation window closes 04:00.

Scheduler, core banking host and FX rate feed correlated. Null rate on a newly onboarded currency pair. Same signature as two prior month-ends.

P1 raised with cause attached. Voice call to the batch owner. MOP staged to apply the fallback rate and restart from the failed step, held for approval.

Null-rate guard added at FX ingest. Batch exit codes promoted to first-class signals. Recurrence watch armed for the next three month-ends.

This is a platform capability, not a published customer deployment. The mechanism, which is governed MOP execution with pre-check, post-check, rollback and approval gating, is running in production today in our carrier estates; see governed day-2 operations across 2,000+ nodes and closed-loop network automation. The banking scenario above is that same mechanism applied to a core banking batch. The timings shown are modelled, not measured at a named bank.