One Outage, Three Clocks: A Friday P1 From First Response to the Month-End Service Credit

At 14:50 Eastern on Friday, 15 January 2027, the primary database behind a scheduling app goes read-only. The vendor is a 40-person SaaS company in Columbus, Ohio. Its biggest customer is a 14-location dental group paying $4,800 a month, and at 15:10 the group's operations manager opens a P1 ticket because no clinic can book, move or cancel an appointment. The on-call engineer fails the database over and the app is back at 17:25. Two hours and thirty-five minutes, start to finish.

That outage now starts three separate clocks, and they do not run on the same calendar. The first-response clock and the resolution clock live in the support agreement and are counted in business hours from the moment the ticket was opened. The availability clock lives in the uptime SLA, is counted from the moment monitoring saw the failure, and is not settled until the month ends on Sunday, 31 January. Monday, 18 January is Martin Luther King Jr. Day, a federal holiday the vendor closes for, and that one Monday is where the clocks drift apart if anyone counts them without the contract's holiday calendar.

This guide walks the incident through the site's calculators in the order the support lead and the account manager actually meet them, using the real outputs, and flags the places where one tool's answer cannot simply be pasted into the next.

The contract terms everything hangs on

Before any calculator is opened, write down what the agreement actually says. In this case the master services agreement defines:

• Business hours: 08:00 to 18:00 Eastern, Monday to Friday, excluding US federal holidays.
• P1 targets: first response within 1 business hour; service restored (a workaround is acceptable) within 4 business hours; a permanent fix within 16 business hours.
• Availability: 99.5%, measured over business hours in each calendar month.
• Service credit: 10% of that month's fee if availability falls below target, claimed in writing by the customer.

The phrase "excluding US federal holidays" matters more than anything else on that list, because every tool below has to be given that calendar, and a count run without it is wrong by a full working day. The US Office of Personnel Management lists Friday, 1 January and Monday, 18 January 2027 as federal holidays, and both fall inside this measurement month.

The incident on one page

When (Eastern)	What happened or falls due	Source of the time
Fri 15 Jan, 14:50	Database goes read-only; app unusable	Monitoring
Fri 15 Jan, 15:10	P1 ticket opened by the customer	Ticketing system
Fri 15 Jan, 15:31	First human response sent (due 16:10)	Ticketing system
Fri 15 Jan, 17:25	Failover complete, service restored	Monitoring
Mon 18 Jan	MLK Day: desk closed, contract clock stopped	OPM holiday list
Tue 19 Jan, 09:10	Restoration deadline under the contract calendar	Ticket tool, US calendar
Wed 20 Jan, 11:10	Permanent-fix deadline under the contract calendar	SLA tool, US calendar
Sun 31 Jan	Measurement month closes	Contract

Clock one: first response and restoration

The support lead's first question on Friday afternoon is simply "when are we in breach?" The Support Ticket Response Deadline calculator answers both of the support clocks at once. Its inputs here: opened 2027-01-15 at 15:10, priority P1, window 8 to 18, Monday to Friday, holiday calendar United States. It returns:

• First response due: Fri 15 Jan, 16:10
• Resolution target: Tue 19 Jan, 09:10
• Response / resolution: 1 / 4 business hours

The response deadline is right and was met with 39 minutes to spare. The resolution target is where the first trap sits. Four business hours from 15:10 uses the 2 hours 50 minutes left on Friday and carries 1 hour 10 minutes into the next working morning, which is Tuesday, because the US calendar removes Monday 18 January; the tool lists it as a skipped holiday. Clear the country and the same run says Monday 18 January at 09:10, a deadline that falls on a day the contract says the desk is closed. Before October 2026 the tool had no holiday input at all and gave that Monday answer, so a desk using it had to move the result by hand. Under this contract the restoration deadline is Tuesday 19 January at 09:10.

In this incident it made no difference, because the failover landed at 17:25 on Friday, well inside either version of the deadline. Run the same ticket opened at 17:30 instead, though, and the first response is due Tue 19 Jan 08:30 and restoration Tue 19 Jan 11:30. Run it without the holiday calendar and both land on Monday, and a desk lead reading that literally would schedule someone to come in on a holiday, or would report a breach on Monday that the contract says cannot have happened until Tuesday morning.

The tiers in this tool are fixed at one and four hours for P1. Our contract happens to match them, which is why it is the right first stop. If your P1 terms differ, the tier picker cannot be edited, and you move straight to the next calculator.

Clock two: the permanent fix

A failover is a workaround. The read-only database still has to be understood and repaired, and the contract gives 16 business hours for that, counted from ticket open. That number is not one of the ticket tool's tiers, so it goes into the SLA Response / Resolution Deadline calculator, which takes any number of business hours. Inputs: start 2027-01-15 at 15:10, 16 hours, window 8 to 18, Monday to Friday, United States. Output: breach at 20 January 2027, 11:10.

The arithmetic is 2 hours 50 minutes on Friday, nothing on MLK Day, ten full hours on Tuesday, and 3 hours 10 minutes on Wednesday. Leave the country out and Monday burns ten hours like any other weekday, which brings the breach forward to Tuesday 19 January at 11:10, a full working day early.

The quickest way to check a deadline like that is to measure the span the other way. The Business Hours Between Two Dates calculator does take a country. From Fri 15 Jan 15:10 to Tue 19 Jan 11:10, with US holidays selected and the 8 to 18 window, it reports 6.00 business hours. With no country selected it reports 16.00. Run it to Wed 20 Jan 11:10 with US holidays on and it reports exactly 16.00. When a deadline and a duration disagree like this, the disagreement is the holiday calendar: one of the two runs was made without it.

Clock three: the month-end credit

Nobody calculates the credit on Friday night. It is an account-management job at the start of February, once the month is closed and every outage in it is known. The SaaS SLA Service Credit calculator measures business-hours downtime against the business hours in the calendar month the outage started in, and like the two deadline tools it takes the holiday list.

Inputs: outage 2027-01-15 14:50 to 2027-01-15 17:25, target 99.5, monthly fee 4800, credit 10%, window 8 to 18, Monday to Friday, country US. Output:

• Business-hours downtime: 2.58 h
• Business hours in January 2027: 190 h
• Measured uptime: 98.640%
• Allowed downtime at 99.5%: 0.95 h
• SLA status: Missed; estimated credit 10% of monthly fee = 480.00

The 190 hours is 19 working days of ten hours: January 2027 has 21 weekdays, less New Year's Day and MLK Day. Untick the country and the month grows to 210 hours, uptime becomes 98.770%, and the allowance rises to 1.05 hours. The status and the $480 do not change in this case, because 2.58 hours is far past either allowance. They would change for a shorter outage, and the threshold is lower than most people guess: at 99.5% over a 190-hour month, anything past 57 minutes of business-hours downtime misses. A run with the outage ending at 15:45 instead (0.92 h) comes back at 99.518% and "Met"; a few more minutes and it flips.

Where the three clocks disagree

Different start times

The two support clocks start when the ticket is opened, 15:10. The availability clock starts when the service actually failed, 14:50, which only monitoring knows. Feed the credit calculator the ticket time by mistake and it reports 2.25 hours and 98.816%. Same verdict here, but on a tighter outage those 20 minutes are the whole margin, and the customer's own uptime log will start at 14:50.

Different calendars inside the same contract

The credit tool removes MLK Day from the month because the US list is selected. The deadline tools do the same only if you select the same list in them. If you take a deadline run without the calendar and a duration run with it, you are mixing a holiday-aware count with a holiday-blind one. Use the same country, window and closure days in all three tools, and check that each deadline tool's "Holidays / closures skipped" line names the holidays the contract excludes.

A holiday outage that does not count

Suppose a second, 40-minute blip hits at 10:00 on MLK Day itself. The dental clinics were open and annoyed. The credit tool with US holidays selected reports 0.00 business hours for it, because the contract's business hours exclude that day. With the country cleared it reports 0.67 hours. Under this contract the zero is correct, and that is worth explaining to the customer before they raise it, rather than after.

Business hours versus the whole month

The same 2 hours 35 minutes measured against all 744 hours of January is 99.653% uptime, which meets a 99.5% target. Measured against 190 business hours, it misses. Neither the tool nor this guide can tell you which one your contract means; the definitions section does. The calculator only does the business-hours version, and its page is explicit about that. The site's post on what 99.9% uptime really divides by works through the difference in more depth.

What none of these tools do

• Holidays the contract adds. The tools know national and selected regional public holidays. A company closure day, or a holiday from another country's list, has to be entered as a custom date.
• Mixed coverage. Many real P1 terms run around the clock while lower tiers use business hours. Both deadline tools have a 24x7 option that turns the target into elapsed hours (the P1 ticket here would then be due for restoration at Fri 15 Jan, 19:10), but it applies to the whole run, so a contract that is 24x7 for P1 only needs one run per tier.
• Paused clocks. Time spent waiting on the customer is not subtracted. Track pauses yourself if the agreement allows them.
• Several outages in one month. The credit tool takes one start and one end. Run each outage, add the business-hours downtime, and divide by the month's business hours yourself.
• Time zones. The tools use the times you type. If the contract's business hours are the customer's, convert first. The 08:00 to 18:00 window here is the vendor's Eastern time, as the contract states.
• Credit caps and claim windows. The estimate is a flat percentage. Caps, tiered credits and the customer's deadline to claim are in the contract, not in the tool.

For the background on why business hours stop at the end of the window, the site's post on why a Friday ticket is not 67 hours old on Monday covers the single-tool basics.

A short checklist for the next P1

1. Copy the contract's definition of business hours, including its holiday rule, into the incident record before anyone calculates anything.
2. Run the ticket tool from the ticket-open time with the contract's holiday calendar selected, and check the skipped-holidays line.
3. For any target that is not a standard tier, use the SLA deadline tool with the same calendar.
4. Check each deadline with the business-hours tool, holidays on. It should read exactly the contract's number of hours.
5. At month end, run the credit tool from the monitoring start time, with the same country and window as the contract, once per outage.
6. Write down which measurement the contract uses, business hours or the whole month, before telling the customer whether a credit is owed.

General information about how SLA clocks and service-credit arithmetic work, not legal advice. Support and availability terms are set by your own agreement; confirm its definitions, holiday rules and credit terms before relying on any figure here.