We added a search bar on the task list page. Tasks will be returned if the search keyword matches or partially matches a task's name or URL. This will help you locate a task faster.
Auto disable tasks if notification delivery failed 5 times in a row
We added an auto disable mechanism if a task's notification delivery failed 5 times in a row.
For example, if a task is configured to notify a Slack channel when certain conditions are met, and that Slack channel no longer exist, after 5 failed attempt to send the Slack message, the task will be automatically disabled, and the admin will receive an email regarding the disablement.
We believe this mechanism will help users identify and fix problematic notifications earlier.
Thank You
Thank you for reading! Hope you enjoy our product and please feel free to send your feedback to us at [email protected]! May the 4th be with you!
With this feature, you can create tasks that will execute only once at a certain time. You no longer have to achieve this by setting up a recurring schedule task and manually disable it after the first execution.
Task notification email address selection
Previously for iHook tasks, users can send email notifications to any email address by filling a text box in the notification settings page without any verification.
Now you need to pick an address from a list that contains all emails that have been verified. This saves you time to enter the address manually, and eliminates the chance for a typo. This also protects our product from being abused by malicious users who try to send spam emails to targeted recipients.
By default, the email that is verified during registration will be available in the list. If you want to send a notification to a new address, you need to verify it by going through a verification process.
Lazy polling for task and receiver history
When viewing task execution history and receiver execution history, iHook UI automatically polls the execution data from the backend every couple of seconds. Previously it fetches all the data from the last 10 executions, which could be a huge amount of data.
Now, this logic is improved by only fetching the entries that is not present in the UI, which dramatically reduces the amount of data that needs to be fetched.
This change also allows us to do more frequent polling since each polling requires much less network resource. You should be able to see your execution info gets refreshed twice as fast now.
Roadblock for task deactivation
iHook automatically deactivates tasks that failed to execute 3 times in a row. In rare cases, there might be system-level issue that causes a large number of tasks to fail consistently. For example, the servers that host our service might experience network issues, which will result in all task executions to fail.
In such cases, while we should address the root cause of such infrastructure issues as soon as possible, we also want to prevent the tasks from being deactivated by the system unexpectedly.
So we rolled out a roadblock feature - if the system deactivated more than 20% of all active tasks for the past 30 minutes, we will disable the task auto deactivation feature until we manually re-enable the feature.
We hope the roadblock feature never needs to be used :)
Thank You
Thank you for reading! Hope you enjoy our product and please feel free to send your feedback to us at [email protected]!
We've been using Okta as our identity provider to manage sign-in and sign-up flows. It had been working great for the past 2 years - the integration could be set up within a couple of hours, and we don't have to worry about implementing and maintain all those sign-in, sign-up, password recovery flows. And it did a great job protecting iHook against malicious bot from registering zombie users.
However, due to the recent pricing change, we've decided that Okta is no longer an economic choice for iHook, and we spent 1 month rolling out our in-house authentication solution.
The new sign-in pages look pretty much the same as before, and you may continue to use your existing credentials (password or Google account) to log into iHook. Compared to the sign-in experience managed by Okta, the new pages are purely HTML-based without any Javascript logic. This reduces the static assets that need to be loaded by your browser and you may expect a faster page loading speed.
We did notice an increase in spam bot registration after the rollout. In response, we deployed a third-party security solution to help mitigate such attacks. So far this has been working well and we've seen a dramatic drop in attack for the last 2 weeks. Since the bot detection is automatic, there's a chance that legit traffic is blocked by the security module, if so please don't hesitate to contact our support team at [email protected]. We'll continue monitoring the site traffic to ensure a smooth site visiting experience.
Custom Slack message support for task notifications
We added support to customize Slack notification messages for iHook tasks. This had been supported for iHook receivers from day one, now it's available for iHook tasks as well. With this feature, you can provide more details when your task's Slack notifications are triggered. Similar to Email and SMS notification messages, you can add template variables such as evaluated condition value and response code. For more information, see our doc page.
HTTP notification status in execution history
For HTTP notifications, we added more details about the notification delivery status, including request headers, request body, response code, response headers, and response body. With this info, troubleshoot HTTP notifications would be easier.
Thank You
Thank you for reading! And thank you for your support of iHook! For any feedback, please feel free to contact us at [email protected]! Have a great weekend!
We are excited to announce our latest product, iHook Receiver! A receiver provides an iHook hosted API endpoint to receive HTTP requests from external resources, and can send email/Slack notifications whenever those requests are triggered.
Receiver is a handy tool to accept webhooks from web services such as SendGrid and Okta, and notify you with the data of your interest. You can use JSON path expression to process and filter webhook request data that is sent to your receiver.
Free plan users can create up to 10 receivers. Each receiver comes with a 20 per minute rate limit for incoming requests. For more details about how to set up a receiver, please take a look at our quick start doc.
Notification status under Task History
We added the Notification Status section for each task execution detail under the history page. With this enhancement, users will have better knowledge about their notification condition evaluation results and notification delivery results for each task execution:
Task history loading performance improvement
We reduced the task execution items per page from 20 to 10. This will improve the task history page's loading speed, especially for tasks with larger response body.
Thank You
Thank you for reading! We look forward to your feedback about our latest product Receiver. Please feel free to contact us at [email protected]! Have a great weekend!
Happy New Year everyone! Hope you are all doing well. It's time for another product update.
New daily email usage limit
To prevent email service abuse, we updated the email quota for free plan accounts: 20 emails per 24-hour period.
When the email quota is reached, the related task will be disabled and an email notification will be sent to your primary email address that is provided during registration.
You may re-enable the task once your quota becomes available again - the sending limit is applied over a rolling 24-hour period, and your quota will be fully renewed after 24 hours. To help you monitor the usage, we rolled out a usage section on the account page, you can check it out here.
We feel like the new quota should be sufficient for regular use cases since too many emails sent during a short period would become noisy anyway. We’ll keep trying to understand our users' email usage patterns and iterate on the quota plan so that our free plan users don't get too annoyed by task disablement due to email overuse.
Task execution error reminder
One pain point of our users is that when their task notifications failed to deliver (e.g. due to misconfigured condition rule, or incorrect delivery email address), it's hard for them to notice the failure, since the task execution was marked as COMPLETED, and they have to expand the task execution detail, and look at the Errors section for any errors.
Now when such failure occurs, the task execution will be marked as FAILED, so it's easier for users to notice the failure without having to expand the execution detail.
On top of that, when a notification delivery failed due to a misconfigured notification condition 5 times in a row, the task will be disabled and an email notification will be sent to your primary email address. We think that a task with a misconfigured notification is incomplete, and disabling the task would help force users to correct their notification setup.
Task disable email notification enhancement
We enhanced the task disablement email notification. Now each email will show detail about the reason for the disablement, such as email/SMS usage exceeds the limit, invalid notification condition, or the HTTP task's response body exceed the limit. This will help users troubleshoot their task setup and help them fix the issue and re-enable the task faster.
New shortcuts
To make task editing experience more smooth, we now support using Esc key to cancel task edits. See here for a full list of shortcuts we supported.
Thank You
Thank you for reading! As always, if you have any feedback on our product and features, please contact us at [email protected], we look forward to hearing from you! Happy New Year!
Happy Halloween! Although Halloween will be different than usual this year, I hope you enjoy the holiday with family and friends while staying safe. Here are the product updates for October.
Sorting options for task list
We added sorting support for the task list page. For the business plan, people can create dozens of tasks, and sometimes it's hard to find a task in the list since they are sorted by created date in descending order.
With the new sorting options, in addition to the current sort by created date option, you can sort by task name and last opened date. This will help you organize your tasks. For example, if you visit some tasks more frequently than other tasks to review the execution history, you may find sorting by Last opened at helpful.
Option to allow insecure server certificates
Before this change, iHook's requests to remote HTTP resources with invalid certificates would end up in FAIL state, with invalid certificate error shown in the task execution detail section under the History tab.
We added an advanced option under the Request Settings section to allow such requests to succeed. While it's a best practice to configure valid SSL certificates for production web resources, you may still need to issue requests to HTTP endpoints where a secure certificate is not readily available. In such cases, you may find this new setting helpful.
Schedule delay for interval-based tasks
When tasks are scheduled to execute in a fixed interval such as every 1 hour, each execution may experience a few seconds delay. Such delay can add up with time and the task schedule may experience a noticeable drift from its original schedule.
The issue was caused by a delay in scanning logic that looks for ready-to-run tasks, in combination with the fact that such delay was included when calculating the next execution date. This issue had been fixed and you should now expect no more than 1 second delay for your task executions across all schedule modes (interval-based and cron-based), with the drift behavior eliminated.
Thank You
Thank you for reading! Our goal is to keep improving our product to provide you a better user experience for scheduling HTTP requests while maintaining our service availability and reliability. This includes minimizing regression along the way by enforcing comprehensive quality control coverage. As always, if you have any feedback on our product and features, please contact us at [email protected], we look forward to hearing from you!
We updated the history chart UI with a dropdown list to make it easier for users to select common metrics such as response time and status code. Of course, you can select the response body option in the dropdown, where a search box will appear for you to draw charts for certain properties from the response body.
This change makes it easier for new users to explore the feature and also makes the chart section more concise. And don't forget that you can add bookmarks for your charts for easy future access. For more details, please see our doc page.
Response Time Metrics:
Response Body Property Metrics:
Follow HTTP Redirect
On the task execution front, we added a setting to allow tasks to automatically follow HTTP redirect when issuing a POST request. Before this enhancement, iHook only follows redirects for non POST requests, as specified in HTTP RFC 2616. Now you can relax the restriction by enabling the task setting under the Advanced Option section.
HTTP Request Header Override
When iHook sends HTTP requests, a couple of headers such as User-Agent and Accept are added by default to maximize the chance for a request to succeed (You can inspect each request's header information under the History section).
Now you can override those pre-defined header values. For example, you can assign a browser User-Agent value such as Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11 to better simulate browser requests. The override will be case insensitive.
Auto Disabling
If a task could not receive a response from the remote side after 15 seconds, and if this happens 3 times in a row, iHook would disable the task and notify you via email. Now we are extending this behavior for tasks with 4xx and 5xx response status code.
We realize that most users would end up with a 2xx status code if their HTTP requests were to achieve something meaningful. With this change, it would allow us to better allocate our task scheduling resource and notify users when requests receive bad status code.
Surely some users would still be interested in 4xx and 5xx status code. To avoid auto disabling, you can create notification rules that check for status code. That way we would know that you are making a conscious decision about the expected HTTP response status code for a task. As long as such rules are present, no auto disabling would occur on 4xx and 5xx status code.
Thank You
Thank you for reading and thank you for your continued support for iHook! As always, if you have any feedback on our product and features, please contact us at [email protected], we look forward to hearing from you!
We are super excited to announce our new task execution data visualization component!
Under the History tab, you can find a new chart component, which you can use to draw a time chart to understand the trend of task execution data such as response time:
What's more exciting is that if your task returns a JSON response body, you can draw a time chart for those JSON properties:
The chart allows you to aggregate a view of a specific data point across multiple task executions, without having to inspect each execution detail.
One common use case of the chart is system monitoring. If you have a task that returns system metrics data in JSON format, you can create charts that show the trend of those data points such as free memory and CPU usage. For your favorite charts, you can save them as bookmarks under the search box, which is just one click away from bringing those charts back in the future.
You can find more instructions about the feature here.
Notification condition for response headers
We enhanced our notification condition component to support checks around response headers.
One interesting use case for this is to detect CORS misconfiguration for static website assets hosted via S3 and CloudFront.
If you host your website images on AWS S3 and put it behind CloudFront CDN, and if the CloudFront distribution is misconfigured, client browsers will have trouble accessing the image with the following error:
Access to image from origin has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
The tricky part is that the missing Access-Control-Allow-Origin header issue only happens occasionally. Setup an iHook task that checks the header value would help identify the issue and help confirm the fix of the issue.
Accessibility enhancement
On the UX front, we added a shortcut for saving the task edit form and notification edit form. Now you can use Ctrl + Enter or Command + Enter (for macOS users) to save the form. We believe this will help make the form editing experience less frictional, hope you enjoy it!
Doc search
We added search capability for our doc and blog sites. A huge shout out to Algolia's DocSearch program, with their help we were able to provide an awesome search experience. If you are considering adding a search feature to your doc site, we highly recommend this program.
It's worth mentioning that if you are considering building your doc site from scratch, take a look at Docusaurus, that's the open-source framework we use at iHook. It's markdown based so the editing experience is pretty smooth. And it has pretty good extensibility - adding a search feature is as simple as adding Algolia's API key and index name in the project config file.
Thank You
Thank you again for your continued support for iHook! As always, if you have any feedback on our product and features, please contact us at [email protected], we look forward to hearing from you!
A lot of worldwide popular products are heavily adopted by their internal team, such as Slack and Notion. In this article, we'll talk about how we use iHook in our daily operations.
Email Notification Volume Monitoring
Email notification is a critical component at iHook, to ensure the component functions properly, we constantly monitor the email notification traffic to identify abuse. There are two ways to approach this: one is to generate a log each time an email is delivered, and use analytics solutions such as Splunk to fire an alert if the email traffic exceeds a certain threshold; at iHook though, we realized that we could achieve this by setting up a scheduled iHook task.
The problem we are solving here is essentially counting email delivery events. So we created a database table that stores all such events.
The schema is pretty straightforward but allows us to store user account id and additional data if we want to investigate further about the event. Whenever an email is delivered, we will create an event of type email.send.success and persist it in the database.
Then we created an API endpoint for us to count the events based on event_type and time range:
Request:
GET /api/v1/events/count?eventType=email.send.success&sinceMinsAgo=5
Now we just need to create an iHook task that monitors the result of this API, and notify us when needed. Here's the task configuration:
Every 5 minutes, the task issues an HTTP request to our event count API and then evaluates a notification rule that checks the count property of the JSON response, when the count exceeds 5000, we will be notified via email.
Note that you may set up additional notifications via other channels such as SMS, Slack, and HTTP, in case the primary channel failed to deliver. Using the same pattern, we created more tasks to monitor events such as task execution failure and user account upgrade/downgrade.
The API runs efficiently since we've indexed the event_type db column. And this approach freed us from uploading log entries to a log analytics solution for monitoring, and thus reduces our cost.
User Growth Tracking
We feel super excited when a new user joins iHook - it's a validation of our product value and means more people could potentially benefit from iHook's automation capabilities. To better monitor user growth, we created a daily iHook email notification task.
iHook uses Okta for identity management, which means most iHook user profiles are stored and maintained at Okta. To retrieve iHook's total user count, we created a daily task that monitors Okta's user API.
Here's the task configuration:
Once everyday, the task issues a GET request to Okta's user API, which returns a list of active user object in JSON format, and then evaluates a notification rule that checks the user list size via the length()JSON path expression, when it changed from its last evaluated value, an email notification will be sent.
Note that the email template contains a template variable${condition.evaluatedSourceValue} that would turn into the actual total user count when the emails are delivered.
The task saved us from implementing a custom notification logic in the user registration flow, and it had been working great so far!
Our focus in July was mainly on service hardening, along with a handy product update around notification rule.
Product Updates
This month we added a new property value comparison rule for notifications - value has changed. This rule is helpful for users who want to be notified when a task's property value has changed from the last execution's value, and not be notified when the property value remains unchanged.
Before this change, users who are tracking a constantly changing property value has to manually update the target value in the notification condition form, to keep the monitor rule relevant, which can be tedious.
For example, a website owner wants to get notified when a new user registers for his website. Previously he can achieve this by creating a scheduled task that calls the website's user count API, and set up a notification rule like below:
This way the user can receive a notification once the count increases. Though he will have to maintain the Target Value to keep the notification rule relevant. Now with the new change, he can use the value has changed option, sit back, and let iHook task do its work:
Infrastructure Updates
This month we added a secondary email vendor to ensure email notification deliverability in case of primary email vendor outage. On July 28th, our primary email vendor was experiencing a major service outage where email deliveries were significantly delayed or rejected for 6+ hours. Fortunately, we've had our failover mechanism in place and delivered our email notifications via the backup vendor.
Infrastructure redundancy is very important to ensure service availability. We'll keep investing in this area to make our service more resilient. Next, we'll explore providing backup service for the following components:
Primary database
Cron scheduler
Task worker
SMS notification service
Server monitoring tool
Ops Updates
On the ops side, to better protect us against hacking activities, we revisited all of our cloud infrastructure vendors' account security settings and enabled MFA for those that haven't yet. This would add a bit more friction during login, but the security benefit is well worth it.
Also, we updated our system health check API permission checking logic, such that we can use less privileged API keys in our 3rd party monitor tool, to minimize the security impact in case our API credentials get leaked.
Thank You
Thank you for reading, and thank you for your trust with iHook. If you have any feedback, please don't hesitate to contact us at [email protected], we look forward to hearing from you!
