Next Steps for Crons - Update & Your Feedback Needed!

[gaprl]

Hey everyone, Gabriel from the Crons engineering team here. 👋

The Crons team was excited to receive feedback from you on how Sentry can improve your development experience with recurring jobs. Since the launch of Crons last month, we've been focused on incorporating your feedback and ironing out any bugs along the way. As we plan ahead for the upcoming months, we want to share our planned roadmap – and request feedback on the various initiatives we want to take!

We've identified the following high-priority features our team is working on right now:

1. Multi-environment support (production, staging, etc).
2. Ability to send arbitrary data with check-ins (such as a standard error on failure).
3. Linking monitor check-ins with errors and transactions.

You can check out our current roadmap here: Crons Roadmap.

Feel free to take a look at the board and upvote or comment on any issues that connect with you. We'd love to hear your use cases and thoughts on implementation.

If you don't see what you are looking for on the board, feel free to leave a comment here.

[kanadaj]

DSN support for check-ins would be handy. I reeeeally don't like the idea of giving an app full read access to a project just to send check-ins.

[ColdHeat]

Hello! When are Cron Monitors expected to leave beta? Would like to have more clarity on pricing and usage before migrating things over.

[therealarkin]

Hey @ColdHeat keep the feedback coming! Have you tried the current offering, how do you like it? What features you would like to see before migrating (besides Sentry commitment to the space). You can see our priorities in Crons Roadmap, and comment on items or here

To answer your question - we now staffed a team around Cron Monitors, so we are definitely committed to the space but don't have final dates yet. We will continue to engage with the community here

[ColdHeat]

I have not tried it yet but am considering it. However it's sort of dubious as there's no indication on what pricing would be or usage limits. Our current solution is self hosted so I don't want to migrate and then have the cost multiply suddenly.

[therealarkin]

@ColdHeat 100% totally understands your worry. We are right now laser-focused on making the product better and love to get feedback from early adopters before we are able to go deep into pricing.
However, philosophically, If you used sentry's more established products, you know we are more affordable and provide superior value compared to anything out there, and intend to keep it this way.

Also happy to jump on a quick call and learn more about your use case, pls email crons-feedback at sentry dot io (or you can comment on the "problem understanding" thread.

Thanks for bearing with us!

[jerome2710]

Any chance we could test the Crons beta functionality in the self-hosted Sentry environment? I can't seem to find if and so in what version of the self-hosted environment this might be released.

[chadwhitacre]

Might require flipping a feature flag, but which one is not jumping out at me. @gaprl?

[chadwhitacre]

Ah, here you go @jerome2710: getsentry/self-hosted#1993.

[jerome2710]

@chadwhitacre Perfect, thanks a lot!

[alexgmin]

Hi,

What's the pricing plan for crons once they are out of beta?

The blog post mentions this:

Also, there is no additional cost for using Crons. Any cron job-related errors are treated just like any other code error and will pull from your Errors event quota.

Cron errors are clear, but how about cron runs? Will it be similar to performance units?

[gaprl]

Hey there, we've recently released our pricing for Crons, learn more in our billing docs. Let me know if you have any questions!

[ColdHeat]

Hi thanks for sharing this information. I just wanted to say that IMO the per-monitor pricing for crons is a bit too much compared to other alternatives. Only one included cron monitor for all tiers is a little excessive as well. Including more monitors for higher tiers would be good at the least.

[alexgmin]

In my case, I have multiple Django commands that are executed in a schedule.

What would be the process to use cron monitoring in a Django command?

Is it as simple as this:

class Command(BaseCommand):
    @monitor(monitor_slug='<monitor-slug>')
    def handle(self, *args, **options):

If so, the documentation should mention this use case, since I think it's a common one.

[ben-z]

How reliable is the Cron ingestion at the moment? I've been testing the Cron feature since a few months ago and almost all of the alerts (timeout/missed) I get are seemingly due to Sentry ingestion issues. I monitor my application with both Healthchecks.io and Sentry. Healthchecks.io has worked consistently the entire time, but I've gotten at least 3 false alarms from Sentry. One of them doesn't show up as an outage on https://status.sentry.io/

[gaprl]

Hey @ben-z, we'd love to know more about these incorrect alerts. What SDK version are you using? Can you share your monitor URL? Feel free to send this over at [email protected]. Thanks!

[ben-z]

Hi @gaprl! I'm currently using sentry-sdk==1.28.1 in Python. Do you know if there's stability improvements in the newer SDKs? I can't seem to see any in the changelog. I'll send the monitor URL to the email and reference this comment.

[ben-z]

This issue persists. I see that v1.43.0 includes a network change (keep_alive). Will apply that and see if it helps. getsentry/sentry-python#2842

[ben-z]

For the record--in the past few months the cron looks like this:

The application never actually went down.

[dargmuesli]

Is it meant to happen that, with one cron monitor available, if I delete one and add it again, I cannot enable it because of depleted quota? I expect the quota to mean "have one max. at any time" not "only enable once per month" :/

It's not that I or anyone else would recreate cron monitors daily to somehow find a way around that limitation as this would remove almost all benefits of having the monitors in place after all. So maybe the limit should be on active monitors, not creation instructions?

[klemmchr]

I have to say, I really dislike the way how payment is handled for cron jobs.

Recently I did create my first cron job (using free capacity). I tested around a bit and deleted it afterwards. Afterwards I did create a new one that should be used for something more meaningful than just fiddling around. Suddenly, I was unable to activate it because my quota has been reached. I didn't really give it too much of a thought and just set a on demand budget for them to get moving again.

I did create and delete another cron job, not paying attention to the subscription page. Two days ago I discovered that I get charged for three cron jobs instead of one. I did create a support ticket to find out what is going on. I was pointed to this help page where it is explained (somehow). But in all honesty, I cannot really read the observed behavior in the explanation provided.
To be clear, I'm totally fine with paying for a full cron job during a billing cycle, even after deletion. Having this sliced up would be a PITA for billing, given the pennies that are charged here. However, I'm not fine with paying for a cron monitor that has been deleted and paying for a new cron monitor at the same time. They should follow a "seats" system of some sort. If I have a deleted cron, I get charged for that. However, if some other cron is created afterwards, it uses the "seat" of the already deleted cron job and I don't have to pay double the amount for only half the amount that I'm using. Paying for a deleted cron job for a full billing cycle (regardless of the activation time) and not being able to use the rest of the days I would need to pay in the billing cycle does not only feel counter-intuitive to me, it's just completely confusing when looking at billing.