Top Questions
Search 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.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?
You can explore and experiment with the Oncall Scheduler REST API here. To use any of the REST APIs, you must first create an API key either in the tenant settings UI, or in the rotation settings UI. The calls available today enable the usage scenarios listed below. If you would like to use the REST API for a difference scenario, and need something different from the API, please don't hesitate to reach out. We love to add REST API calls as soon as we hear about a customer scenario.- Sync a rotation schedule somewhere else. This is the most common use of the REST API. Use the REST API call to GET a Rotation, transform the data, and write the schedule where you want it. Customers today use this for writing into internal-only custom alerting systems and to write to shared Google Calendars.
- Add a Custom Alerting System as a sync target available to all rotation administrators from the Oncall Scheduler UI. This is the most advanced REST API scenario, but also gives the best user experience for rotation administrators who need to sync schedules to a custom internal-only alerting system. To set this up, you need to start by registering your Custom Alerting Sync solution in the tenant settings UI. When you've done this, the Oncall Scheduler UI will include links to configure your custom schedule sync solution for all rotation administrators to use. Your sync service will get unauthenticated HTTP 'there was a schedule change; it's time to sync' pings from the Oncall Scheduler. When your schedule sync solution has run, you can use the Custom Alerting Service status REST API call to report back whether the sync was successful.
- Write vacation or Personal Time Off (PTO) time into Oncall Scheduler as off duty bids. To make scheduling management easier for your oncall rotation members, you can read their vacation/PTO information from any system you use internally (e.g. an ERP system like WorkDay) and automatically create Off Duty Bids in Oncall Scheduler for that vacation/PTO time. To do this, use the calls to create, read, and delete Off Duty Bids for users.
- Add and remove members automatically from rotations, as membership in a directory group changes. If your oncall rotation membership maps to the membership in a group in your directory (e.g. AAD/EntraId, or Google Directory), can you automatically keep the membership in sync between the two by adding and removing members from Oncall Scheduler rotations automatically.
- Automatically remove anyone who leaves your company from all rotations they are part of. You can use the User REST APIs to get information about a user with a given email address (e.g. which rotations they are members of), and to delete all the user rotation memberships for a given User.
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.
Can we use Okta authentication with the Oncall Scheduler?
Yes, see Configure authentication through Okta for a step-by-step guide.How does TimeWeSp, for the Oncall Scheduler product, handle requests for disclosure of Personal Data by Law Enforcement Authorities?
TimeWeSp, and the Oncall Scheduler product, have never so far received a request from a government agency to disclose customer data stored by the Oncall Scheduler. If we ever receive such a request in the future, we will first redirect the request to the customer. If the requesting agency should decline to do so, we will only disclose customer data in response to a valid legal process. TimeWeSp requires a search warrant issued by a court of competent jurisdiction or the equivalent legal process in the applicable jurisdiction to disclose customer data. TimeWeSp does not voluntarily provide governments with access to any data about users for surveillance purposes. Unless TimeWeSp is prohibited from doing so, TimeWeSp will notify the customer of the request before disclosing any customer data, so the customer may seek legal remedies. If TimeWeSp is legally prohibited from notifying the Customer prior to disclosure, we will take reasonable steps to notify the Customer of the demand after the nondisclosure requirement expires.TimeWeSp requires that any individual or entity issuing legal process or legal information requests (e.g., discovery requests, warrants, or subpoenas) ensure that the process or request is properly domesticated. For data stored in the United States, TimeWeSp does not accept legal process or requests directly from law enforcement entities outside the U.S. or Canada. Foreign law enforcement agencies seeking data stored within the U.S. should proceed through a Mutual Legal Assistance Treaty or other diplomatic or legal means to obtain data through a court where TimeWeSp is located.