Top Questions

Search with your browser's "Find in Page", or pressing Ctrl+F
FAQ
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.
I'd like to automatically sync the schedule from Oncall Scheduler into another tool. How do I do that?
You can create custom software tools to sync schedules from Oncall Scheduler into other systems, beyond those natively supported. You can sync the schedule into other places like a Google Calendar, or into alerting systems you use to get phone calls and text messages to oncall engineers. If you build a simple tool which a user has to kick off manually to do a sync, or that kicks off every X hours, you only need an Oncall Scheduler REST API Key.
If you set up a web app which integrates with the Oncall Scheduler UI, and where your users can go to configure sync to be triggered whenever there is a schedule change, you'll also need to configure Custom Alerting System URLs. API Keys can be configured by administrators for your whole tenant, or for specific rotations. Custom Alerting System URLs can be configured by tenant administrators.
What REST API calls are available for the Oncall Scheduler?
There are 2 REST API calls available today. Please let us know through kristian@timewesp.com if you would like us to add more REST API functionality.
Both are under:
https://oncallschedulerapi.azurewebsites.net/<your tenant domain (e.g. timewesp.com)>/...
You authenticate for these calls by inserting a header in your HTTP request, with the format
'Authorization: Token <the API key you get in the tenant or rotation settings pages>'
  • Get the schedule and other data for a rotation. This is the call you'll use to get the schedule data to sync into your alerting system.
    Path:
    .../Rotations/<the rotation id in Oncall Scheduler>
    HTTP Verb:
    GET
  • Share success or failure/error information about a sync attempt back to Oncall Scheduler. If you share this data back to Oncall Scheduler, it'll send out emails to rotation admins, and display information about the sync status in the UI. Only tenant administrators can configure custom alerting services URLs.
    Path:
    .../CustomAlertingServiceStatus/<the id of the custom alerting service you get from the tenant settings page>
    ?rotationId=<the id>
    &success=<the string 'true' or 'false'>
    &status=<a human readable string with success status or error information>
    HTTP Verb:
    POST
The backup pattern of each member being backup before or after their primary shift isn’t what we want to do. How can we do backup differently?
When you create a rotation, the first page lets you choose whether the rotation should schedule everybody to be backup during the shift before their primary duty, or during the shift after their primary duty, or whether there should be no backup scheduled as part of the rotation. Those are the 3 most common and simple backup scheduling patterns used across the industry. But you can use the Oncall Scheduler to set up more complex backup patterns. To do this, create separate rotations for ‘primary’ and for ‘backup’. When you create each of those rotations, select ‘There is no backup scheduled for this rotation’. This enables a lot of flexibility in how backup duty is assigned. You can have a completely or partially different set of people doing primary vs. backup assignments. You can make backup shifts have different calendar layout than the primary shifts (e.g. more or less days, starting and ending at different times). You can have more than 2 layers of oncall responders (e.g. create a 3rd rotation called ‘tier 3 response’).
If you create separate rotations for primary and backup, and some team members are included in both rotations, you can ensure that nobody will be scheduled to be their own backup by using the ‘Block cross-rotation overlapping shift assignments’ configuration in the Rotation Settings.
When you set up synchronization of the schedules from Oncall Scheduler into alerting systems like PagerDuty, Opsgenie, Grafana Oncall, etc., this will work well with having separate rotations for primary and backup. You configure who gets called in what order in the alerting system.
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: kristian@timewesp.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.
Why are off-duty day bids to avoid weekdays each week not available as an option in the UI for all rotations?
Off-duty day bids to avoid being oncall on specific weekdays each week (for example if you have soccer practice each Wednesday afternoon) are only available for rotations which have enough shifts per week such that a bid like that won’t mean bidding to avoid all shifts.
For this option to be available to rotation members in the My off-duty days page, the rotation must have >2 shifts/week if there is no backup for the rotation, or >3 shifts/week when rotation members are backup the shift before or after they are primary. When this is true, the rotation is likely (although not guaranteed) to have at least 1 shift per week where neither primary nor backup duty covers each weekday.
What features are not available after the free trial expires, and before we create a subscription?
When the free trial for a rotation expires, and while a rotation is in an unpaid state, you can still use the rotation mostly as you and your users are used to. It will become less helpful in solving your scheduling over time though, as these features stop working for the rotation:
  • New shifts are no longer created at the end of the shifts already available.
  • Automatic shift allocation to rotation members, based on off-duty preferences and credit balances, stops.
  • There will be no urgent shift allocation email auctions to find new members to take on shifts that unexpectedly opened closer in time than the auto-allocation horizon.
As soon as you create a paid subscription for the rotation, these things will start happening again.