Top QuestionsSearch with your browser's "Find in Page", or pressing Ctrl+F
Is it risky for us to take a dependency on a small vendor like TimeWeSp and the Oncall Scheduler?There is pretty much no risk. Even in a worst case scenario where you're using the Oncall Scheduler, and the service disappears, you'll have a schedule that is set up through the auto-allocation horizon (default: 6 months), so will have plenty of time to consider other scheduling solutions to use. That scenario is also unlikely to occur. We at TimeWeSp are investing continuously in improving the Oncall Scheduler, and plan to keep it going for decades to come.
What should I think about when getting started to use the Oncall Scheduler?It's pretty simple. Either watch the how-to video on the homepage, or go through these steps: How to get started with Oncall Scheduler in 5 minutes.
How do I get schedules in PagerDuty and the Oncall Scheduler to be in sync?Check out How to sync schedules into PagerDuty for a step-by-step guide.
Isn't this kind of overkill? What's wrong with the manual scheduling, or the less predictable round-robin scheduling we have been using?The manual or round-robin scheduling most oncall teams use when they don't have a tool like the Oncall Scheduler, has been working well for some people. But for others it has been a cause of concern and frustration due to the lack predictability, control, and fairness. Different people have different life circumstances. Just because a schedule which changes in unpredictable ways isn't a challenge for you, don't assume it isn't a problem for others. E.g. some people feel they kept getting assigned holiday shifts year-after-year and there was no algorithm/system to ensure fairness about holiday shift assignments. E.g. People could schedule a vacation a year in advance and not have a proactive way to avoid getting assigned oncall work for the same dates, and then their only recourse would be to find a kind soul who wouldn't mind exchanging shifts.
The Oncall Scheduler app helps people with concerns like this overcome those issues, while still not requiring any action from others who don't mind a more random shift assignment with less preference setting.
What should we do if a feature we need is missing from the tool?Send an email to: email@example.com.
What happens when a rotation member leaves the rotation?When a rotation member leaves the rotation, the first thing which happens is that their credits (whether positive or negative) are re-distributed equally among the other members. Then, all remaining members lose 1 credit since the total credit pool should decrease to preserve the credit meaning of '1 credit equals 1 future shift which will be auto-allocated to someone else before one gets allocated to you'.
The shifts which were assigned to the departing member are opened up for others to take on. When the next regular auto-scheduling runs, it will notice any open schedule holes within the auto-allocation horizon (default: 6 months) and kick off a process for filling those holes. This process has 4 steps. Steps 1-3 are to send an email to the remaining rotation members notifying them that there is an urgent shift to fill and letting them know that the credit rewards for taking this shift are unusually large. The emails gradually increase the reward from 1.5x the normal credit reward, to 1.75x and then to 2x. The emails are sent with about 3days in-between each. 3 days after the '2x' email, the open shifts will be auto-assigned using the normal auto-assign process and the members who get a shift assigned will get 2x the normal credit rewards for that shift.
What happens when a rotation member is added to a rotation?When a rotation is already scheduled, and a new rotation member is added, the new person starts out with '0' credits. This places them behind any other members with positive credit balances, but ahead of any other members with negative balances.
When a new member is added, all other members in the rotation also receive 1 extra credit since the total credit pool should increase to preserve the credit meaning of '1 credit equals 1 future shift which will be auto-allocated to someone else before one gets allocated to you'.
What happens when a rotation member runs out of credits (reach '0')?The system allows rotation members to be in credit 'debt' (i.e. having negative credits). This is not unusual. The rotation members who book themselves for specific shifts far into the future will generally have large numbers of credits, while members who rely on bids to avoid certain dates, and auto-scheduling for getting shifts allocated to them, will generally be in debt. There's nothing wrong with being in credit debt. It just means that member is relying more on auto-scheduling instead of explicitly selecting the shifts they want to work.
How much is a credit worth? How should I think about how much to bid to avoid a date or holiday?Each credit you spend is roughly equivalent to reducing the time before you are auto-assigned your next shift by 1 shift period. E.g. if you have 12 credits and you bid 2 for a date, and someone else takes the shift you bid for, you'll now have 9 credits (because you paid them the 2 you bid, and you also paid them the 1 which all other members pay to someone who is assigned a shift). Your next auto-assigned shift will now come a few (approximately 2) shift periods earlier than it would have if you hadn't made the bid.
How likely you are to get auto-assigned a certain shift is a function of both how many credits you have at the time the auto-assignment is made, and how much you bid to avoid that shift. A bid credit is weighted much more heavily than an accumulated credit for this comparison. See the other question here for the exact algorithm used to determine who is auto-assigned a shift.
How many bids can a person place to avoid shifts?Rotation members can place as many bids as they like. Placing lots of them will have them paying credits to others (for taking those shifts) at a high rate though, and the person who placed the bids will quickly have very few credits. Placing a bid on a given shift does not guarantee that the bidder won't be given that shift. There's an equation balancing bids and credit differences between members when allocating shifts. A person who tried to game the system by placing an unreasonable number of bids to avoid shifts would quickly find themselves with a huge credit debt, and the equation would balance things so they would start getting auto-scheduled for shifts even though they had bid to try to avoid them.
What is the equation used to determine which members gets allocated a shift at the auto-allocation horizon (default: 6 months)?The algorithm for how shifts get auto-assigned is pretty simple. For rotations which have backups scheduler, people who are already oncall right before/after are excluded (nobody should be their own backup). Then the person with the lowest score for 'personCredits + PersonBidsToAvoidShift * NumRotationMembers' is picked. Automatic assignment of shifts happens at the auto-allocation horizon (default: 6 months) into the future, and when unexpected holes open up in the schedule because someone left the rotation.
Does it make sense to enter bids to avoid getting scheduled on certain dates? Isn't it smarter to always just self-assign shifts instead, to avoid getting any shifts auto-allocated?No. It does not always make more 'maximize credits' sense to self-allocate than to use bids to avoid certain shifts. When you self-allocate a shift, you pay a fee for each shift you self-allocate (for shifts which are beyond the 6 month auto-allocation horizon). Let's assume this fee is '1 credit', although it can be different in some circumstances. You can see how much this fee is, in the credit value column in the Schedule page for your rotation.
When you make a bid, you can bid as low as 0.1 credit to get a significantly lower chance of getting auto-allocated that shift. Let's illustrate with an example. The math is different for every rotation since it depends on the number of rotation members and shift length. But let's assume a rotation with 20 members, with 2 shifts per week. In such a rotation, on average, each member will work (52*2)/20 = 5.2 shifts per year. To self-allocate enough shifts to be unlikely to ever get auto-allocated a shift, you'll pay fixed self-allocation fees of 5.2 credits per year. On average (ignoring variations due to you self-allocating shifts which others have bid for), you would end up working about 5.5 shifts for such a year. Someone who didn't self-allocate at all, would on average work 5.2 shifts for that year. If the person who didn't self-allocate any shifts bid 0.1 to make themselves unlikely to be auto-allocated 4 personal special days (birthdays, anniversaries), and bid 1 credit to avoid 3 common holidays they prefer to avoid, they would have spent 3.4 credits (compared to the 5.2 you spent on self-allocation), and in a rotation where many people don't enter any bids, that bidder would have a very good chance not to get assigned work on any of the dates they bid to avoid. See the question above about how the equation which weighs bids looks to understand how even a small bid makes a big difference in whether you get assigned a certain shift, even if you have the least credits in your rotation.
Can this scheduling solution be used for follow-the-sun staffing? E.g. can one set of people work New York days and another set of people work Bangalore days?Yes, the Oncall Scheduler works well for scheduling separate sets of people, who will each be on active oncall duty during separate hours of a day. You set this up by creating a separate Oncall Scheduler rotation for each set of people who'll handle a portion of the day. The two rotations are managed completely separately in Oncall Scheduler. There is no sharing of credits or anything else between them. You should set up the schedule and shift for each rotation to cover only the hours they'll each work. The two rotations are not connected until you configure how they should sync into the alerting system you’re using (e.g. PagerDuty). To have both rotations sync into the alerting system predictable, you need to set up both rotations to use the same time zone. Otherwise you'll have complex time zone differences around changes between daylight savings time and standard time to manage.
Is there anything to prevent people from cheating by self-allocating shifts at the end of the available shifts, and then continuously vacating shifts that are getting close to the auto-allocation horizon, and self-allocating even more shifts at the end of the available schedule?Yes, there are mechanisms to prevent 'cheating' like this. Before talking about the system rules which prevent this, we should first mention the more important mechanism which should prevent any kind of cheating by people trying to get out of working oncall: your solidarity and responsibility to your teammates. This tool isn't a game to manipulate and beat. It's a tool to help you and your teammates easily and fairly distribute the difficult oncall work you are collectively responsible for.
An important part of the Oncall Scheduler is that rotation members have control over when they are scheduled to work. This includes the ability for members to avoid oncall work during parts of a year, and to instead do lots of oncall work at other parts of the year. But there's a limit to this flexibility. A member can only self-assign as many shifts beyond the auto-allocation horizon (default: 6 months), as the number of shifts each member is expected to work for the rotation during a year. If a member has more than this number of shifts self-assigned beyond the auto-allocation horizon, and they try to self-assign another shift, this will be blocked with an error message. This means that someone who keeps trying to postpone all oncall work by self-assigning shifts far into the future, and vacating shifts that are getting close to the auto-allocation horizon, will soon find themselves in a situation where their credit balance is lower than everybody else's, and they are unable to self-allocate more shifts to get more credits. At that point, this person will get auto-allocated shifts frequently, until they let some of their self-allocated shifts go before the auto-allocation horizon such that they can self-allocate more shifts again.
How does Oncall Scheduler keep API keys and other configuration for 3rd party alerting systems like PagerDuty, Opsgenie, and Grafana Oncall, safe?Overall, Oncall Scheduler abides by the security best practices you would expect from a business solution. For example, having a process in place to ensure all dependencies (e.g. the OS and web server Oncall Scheduler runs on, but also internal components) are updated shortly after new security updates are available. Another example is the use of password-less service accounts to run all parts of Oncall Scheduler, used for access such as from the web app to the data store.
In addition to the protection applied to all of the Oncall Scheduler service, alerting system configuration has an additional layer of protection. That configuration is only stored in encrypted form at rest. A decryption key stored in Microsoft's Azure Key Vault, is retrieved and used in-memory for the short duration it takes to decrypt and use the configuration to write a schedule to an alerting service.