How coverage is calculated

Coverage answers one question: how many people will you actually have on a given day?

It is a single number per team per day. Not a percentage of a target, not a headcount, not a guess. It is produced by adding up how available each member is on that day.

coverage for a daysum of every active member's availability that day

Availability per member is a value from 0% to 100%, meaning how much of that person’s time is available. Coverage is the total, expressed in people. A team of six where one person is on leave, two are half-committed elsewhere, and three are fully available has a coverage of 4.0 for that day.

The rest of this page explains where each member’s availability comes from, and the order that wins.

The specificity ladder

For each member, on each day, availability is resolved through four tiers, from least specific to most specific:

Baseline: permanent, per member.
Non-working days: the working week, on the workspace or on the member.
Group events: geographic, by match.
Member events: one person, one span.

Tiers are a mental model, not a strict replace. Values are never multiplied across tiers. A member with a 50% baseline and an event at 50% is at 0.50 for that day, not 0.25. On an ordinary working day a member event does not replace a non-zero group event: both apply, and the lowest value wins (a 100% member event with summer hours at 50% is 50%).

Within a tier, the lowest availability wins. Two overlapping member events do not average and do not add.

How a day actually resolves:

Non-working time (a non-working day for that member, or a 0% group event matching them): the lowest value among member events set to count on non-working time. If there are none, 0. Baseline and other group events are not consulted.
Ordinary working day: the lowest value among all applicable member and group events. If there are none, the baseline.

Then every member’s result for that day is added together. That total is coverage.

Two caveats sit on top of the ladder. Without them, a two-week project looks like a fourteen-day claim, and a Saturday on-call looks like a bug.

A member event does not win just because it exists. A work event is a claim about working days unless it is set to count on non-working time. Training from Monday the 10th to Friday the 21st means the ten working days, not fourteen calendar days. The weekends inside it stay at zero.

That setting applies to non-working time only. On an ordinary working day it has no effect. A flagged member event still combines with a non-zero group event (reduced-hours site days, summer hours) under the lowest-value rule. The flag changes weekends, member non-working days, and 0% closures. Nothing else.

Each step is covered below.

Baseline availability

Baseline availability is how much of a person’s time is yours before any event exists. It is the fallback for unscheduled time, and it applies on every ordinary working day where no event covers the member.

Most people sit at 100%. A baseline below 100% describes a permanent arrangement rather than an absence: a split role, regular training that takes part of the week, an engineer who owes half their week to escalations.

Member	Baseline	Availability on an ordinary working day with no events
Dana	`100%`	`1.00`
Ben	`80%`	`0.80`
Priya	`60%`	`0.60`

Baseline also seeds the default value offered when you create a new event (min(event type default, member baseline)), so a 100% on-call event on a 60% member is offered at 60%. That is a convenience in the creation form, not a rule of the engine. The value is editable on the event, and once saved the engine uses the saved value.

Events

An event carries an availability value: how much of the person’s time remains available while the event runs. The value is inherited from the event type, which inherits from its category, and either can be overridden on the individual event.

That value is availability remaining, not time consumed. Annual leave at 0% means fully away. A project at 50% leaves half of the person’s time available.

Starting points from the default configuration (types inherit the category value unless you change them):

Category	Event type	Availability
Planned Time Off	Annual Leave	`0%`
Unplanned Time Off	Sick Leave	`0%`
Internal Operations	Training	`50%`
Internal Operations	Project	`50%`
Internal Operations	Onboarding	`50%`
Core Operations	Standard Work	`100%`
Reactive Operations	On-call Duty	`100%`
Reactive Operations	Stand-by Duty	`100%`
Holidays	Public Holiday	`0%`

These are starting points, adjustable per workspace and per team. Other leave types in the default set (Parental Leave, Personal Leave, Emergency Leave) also sit at 0%. Team-specific demo types can differ. Training has a different effect on a network operations team than on a claims desk.

Events at 100% count toward coverage

An event does not have to reduce anything. On-call duty and standard work sit at 100%, so a member with only an on-call event on a working day contributes a full 1.0 to coverage. The event exists so the rotation is visible and reportable, not to move the number.

This is the most common misreading of the model: an event is a description of a period, not a deduction from it.

Whether that same on-call event counts on a Saturday is a separate setting, covered under Non-working time.

Recurring and unconfirmed events

Recurring events are expanded into individual occurrences before the calculation runs. The engine sees concrete dated occurrences, never the rule.

Unconfirmed events do count. Confirmation state affects how an event is presented on the timeline, not the coverage figure.

Overlapping events: the lowest value wins

Two events of the same type may not overlap on one member. Events of different types may overlap, and that is the override mechanism. Someone on a long project who falls sick logs a one-day sick leave over the top.

When more than one event applies to a member on an ordinary working day, the lowest availability value wins. Visual stacking (zIndex) is display-only. It does not change coverage.

Chen, Tuesday
  Project      50%
  Sick Leave    0%
  -----------------
  Availability  0%   (the lowest)

Not the average, and not the highest.

Not averaged. Averaging 50% and 0% gives 25%, which reports you as a quarter available while you are off sick.
Not multiplied. Multiplying compounds two descriptions of the same period into a reduction neither of them claimed.
Not the highest. Taking the highest would report a sick member as half present.

The lowest value is the only rule that keeps the number honest: if any applicable event says the person is unavailable, they are unavailable.

Non-working time

A day is non-working time for a member when it is a non-working day for them, or a group event at 0% matches them that day (a public holiday, an office closure).

On non-working time the member contributes 0, unless a member event is set to count on non-working time. Then availability is the lowest value among those flagged member events.

On non-working time, non-zero group events are ignored entirely. A 50% summer-hours group event on a Saturday with a flagged on-call at 100% gives 100%.

Group events cannot carry that setting. Only member events can.

The setting is stored on the event type as a default, and you can change it on the individual event. If neither is set, the event does not count on non-working time.

Non-working days themselves are set as a working week on the workspace, usually Monday to Friday, and any member can override that with their own set. They are part of who a member is, not a recurring event to maintain. A four-day contract is Friday off. You do not need to create a repeating Friday absence.

This is deliberately different from a reduced baseline. Both describe less of a person over a week, and they answer “how many people do we have on the 14th” differently:

Member	Arrangement	Mon	Tue	Wed	Thu	Fri	Week
Ana	Friday non-working	`100%`	`100%`	`100%`	`100%`	`0%`	`4.0`
Ben	`80%` baseline	`80%`	`80%`	`80%`	`80%`	`80%`	`4.0`

Same weekly total, different Fridays. Baseline does not leak onto Saturday for either of them.

A day is treated as a working day for the team as a whole if any member of the team is not on a non-working day, or any member has non-zero availability that day. Alerts skip days that are not working days, so a quiet Sunday is not reported as a coverage breach, while Saturday on-call that counts is visible to alerts. A public holiday on a Tuesday still reads as a working day with zero coverage, which is a real gap.

Weekend on-call that counts

Maya is on call on Saturday. The workspace week is Monday to Friday. The on-call event is at 100% and is set to count on non-working time.

Saturday is non-working time. The flagged event applies, so Maya contributes 1.00.

A span that does not count on the weekend

Luca is on two weeks of training at 50%, Monday the 10th through Friday the 21st. The event is not set to count on non-working time.

The ten working days are at 0.50. The two weekends inside the span stay at 0. A work event is a claim about working days until you say otherwise.

Saturday overtime on a type that normally does not count

Priya logs a single Saturday of approved overtime on a Project type. Project’s type default does not count on non-working time. The event is set to count, at 50%.

Saturday is non-working time. The flagged event applies, so Priya contributes 0.50. The type default did not have to change for the rest of the team’s projects.

Volunteer for a holiday, then sick leave

Tom volunteers to work a public holiday (0% group event, so the day is non-working time) and sets that member event to count, at 100%. He then logs sick leave over the same day, also flagged, at 0%.

Both flagged member events apply. The lowest value wins. Tom contributes 0.

Group events and geographic targeting

Group events apply to everyone whose location matches, rather than to a list of names. Public holidays, office closures, shutdown weeks.

You pick a country when you create a group event. Matching then uses the most specific level the event declares:

Country. The event’s country must match the member’s country.
Subdivision, if the event sets one. Must also match. Some countries need a subdivision (a state or region); others do not.
Locality, if the event sets one. Must also match, for example a city.

An event that declares only a country matches every member in that country. An event that declares a country and a subdivision matches only members in that subdivision.

Members without a country code are matched by no group event. Location is never inferred. If a holiday appears not to be applying to someone, their country code is the first thing to check.

On an ordinary working day, a matching group event enters the same lowest-value rule as member events. On a 0% group event the day is non-working time for matching members, and the non-working time rule applies instead.

A public holiday falling inside someone’s annual leave counts once, not twice. Both are at 0%, and the member contributes 0 either way. Overlaps do not double-subtract, because nothing is being subtracted.

The sum

Once every member has an availability value for the day, coverage is their total.

Worked example. Six active members, one ordinary Tuesday:

Member	What applies	Availability
Ann	Annual Leave `0%`	`0.00`
Bob	Training `50%`	`0.50`
Chen	Project `50%`	`0.50`
Dana	No events, baseline `100%`	`1.00`
Erik	No events, baseline `100%`	`1.00`
Fay	On-call Duty `100%`	`1.00`
Coverage		`4.00` of 6 people

Six people on the roster. Four people’s worth of availability on Tuesday.

Note Fay. She is on call, an event sits on her row, and she still contributes a full person. Note also that the sum is unweighted: seniority, role, and tenure do not change the arithmetic. Coverage counts people, not capability.

Why headcount rather than a percentage

Coverage is expressed on a scale of 0 to N, where N is the number of members, rather than as a percentage of the team.

Staffing requirements are usually written that way. “We need five people on the desk” is a number you can compare directly against coverage.
A headcount does not shift underneath you when somebody joins or leaves. A normalised percentage is not comparable across time when the member set changes: 80% of twenty is not 80% of twenty-five.
Headcount converts to a percentage without losing anything. The reverse is lossy.

You can still read the figure as a percentage. That is a display choice, made per view, over the same underlying number.

Fractional results are correct

Coverage values like 20.5 or 14.1 are not rounding artifacts and not a bug. They are the point.

Half of a person’s time is a real quantity when someone is in training half the day or splits their week between two desks. A present-or-away flag has to round each of those to fully available or fully away, and rounding the wrong way on twelve people compounds into an error of several people on the day it matters.

Most people, most days, are simply present or away, and for them the model produces 1 and 0. The value of the fractional model is the exceptions:

Someone in training is reachable but not on the queue.
Someone splitting their week between support and another department is permanently partial.
Someone on call is fully counted, and “present” does not tell you it is a rotation.

Each of those is a fraction of one person’s time, and those fractions add up cleanly.

What does not enter the calculation

Time type

Every event category carries a time type: Primary, Secondary, Standby, or Non-working. It classifies what a period counts as for time-attribution reporting.

Time type never enters the coverage calculation. Availability and time type are two independent dimensions of the same event. Time type also does not decide whether non-working days inside a span count. That is the non-working-time setting on the member event.

A member on standby duty is fully available for coverage, at 100%, and separately attributed as standby time in the Time Distribution report. Reclassifying a category’s time type changes the reports and leaves every coverage figure untouched.

This is why Core Operations and Reactive Operations both sit at 100% and are still separate categories: the same amount of a person, doing a different kind of work.

Deactivated members

Coverage sums active members. A deactivated member contributes nothing and does not appear in the team size the reports show.

Anything intraday

Temprix plans in whole days. Coverage answers how many people you have on the 14th, not who covers 14:00 to 18:00. Working hours are recorded on a member and used for presence display, and they do not shape the coverage figure.

Realtime presence

Coverage is scheduled, not observed. It is built from the events on the timeline. Someone who is logged in and someone who is not are indistinguishable to it.

Display modes

The number is the same in every mode. Only its presentation changes, per view.

Mode	Shows	Tuesday, from the example above
Members Available	The coverage figure itself	`4.0`
Members Unavailable	Team size minus coverage	`2.0`
% Available	Coverage as a share of team size	`67%`
% Unavailable	The inverse	`33%`
Target Available	Coverage minus target coverage	`-1.0` against a target of `5`
Target Unavailable	Target coverage minus coverage	`1.0` against a target of `5`

Target coverage is set per team, on the same members-available scale as coverage itself, and can be overridden per view. It is drawn as a dashed line on Coverage Outlook, with below-target segments carrying colour. A target of 5 on a twelve-person team means five people on the desk, not five percent and not five percent of twelve.

Target is a reference line, not an input. Changing it changes what the chart highlights and what alerts fire on. It never changes a coverage figure.

Check your understanding

A team of five, on a Wednesday. The workspace working week is Monday to Friday.

Maya: baseline 100%, no events.
Tom: baseline 100%, on-call duty at 100%.
Sofie: baseline 60%, no events.
Luca: baseline 100%, project at 50% (not set to count on non-working time), and a public holiday group event at 0% matching his country.
Priya: baseline 100%, Wednesday set as a non-working day for her, with a training event at 50% spanning it that is not set to count on non-working time.

Answer

Member	Resolution	Availability
Maya	Ordinary working day, no events, baseline applies	`1.00`
Tom	Ordinary working day, event applies at `100%`, and it counts	`1.00`
Sofie	Ordinary working day, no events, baseline applies	`0.60`
Luca	`0%` group event makes the day non-working time; unflagged project ignored	`0.00`
Priya	Non-working day; unflagged training ignored	`0.00`
Coverage		`2.60` of 5

In % Available the same day reads 52%. Against a target of 4, Target Available reads -1.40.

Where to go next

Coverage Outlook plots this figure forward across a period, against your target.
Coverage alerts check it on a schedule and email you when it drops.
How availability works covers where the inputs come from: baselines, event types, group events, and the timeline.
Time Distribution is the retrospective view, attributed by time type rather than availability.